# member-console

Member console application for users to create, acccess, and manage their accounts associated with the Wiki Cafe MSC (multi-stakeholder co-operative).

## Database Management

This project uses [pressly/goose](https://github.com/pressly/goose) for database migrations and [sqlc](https://github.com/sqlc-dev/sqlc) for type-safe SQL code generation.

### Database Migrations

Migrations are embedded in the binary and run automatically on application startup. The CLI also provides migration management commands (`migrate up`, `migrate down`, `migrate status`).

### Creating New Migrations

```bash
# Install goose CLI tool
go install github.com/pressly/goose/v3/cmd/goose@latest

# Create a new migration
cd internal/db/migrations
goose create your_migration_name sql
```

### sqlc Code Generation

sqlc generates type-safe Go code from SQL queries and migration files. Database models and query methods are automatically generated from the migration schema and SQL files in `internal/db/queries/`.

```bash
# Regenerate sqlc code after schema or query changes
cd internal/db && sqlc generate
```

## Building and publishing container image

Building and publishing the container image is done using Docker Buildx. This allows us to build multi-platform images for both ARM64 and AMD64 architectures.

```bash
docker buildx build \
  --platform linux/arm64,linux/amd64 \
  -t git.coopcloud.tech/wiki-cafe/member-console:latest \
  -t git.coopcloud.tech/wiki-cafe/member-console:$(date +%Y-%m-%d) \
  --push \
  .
```

## Deploying image to production

### Generating Secrets

To generate secure values for `session-secret` and `csrf-secret`, use the following commands:

For `session-secret` (a base64-encoded random string):

```bash
openssl rand -base64 32
```

Example output:

```
rJcniy2aWl3vwBcrMJfqsTL+Wys7EwDx/RC+DRrKcYg=
```

For `csrf-secret` (a 32-character hexadecimal string):

```bash
openssl rand -hex 16
```

Example output:

```
e157b42a5b608882179cb4ac69c12f84
```

Ensure these secrets are securely stored and persisted for application use.

## Development notes:

### High priority

Existing issues to be addressed before initial production deployment:

- [x] Currently, only sites created via the member console are in the local DB. We need a solution to sync existing sites from the FedWiki farm and periodically update them if they are changed outside of the member console. (Implemented via `SyncFedWikiSitesWorkflow` with Temporal Schedules)

Next features to implement after initial production deployment:
- [ ] Membership management
  - [ ] Allow users to view and manage their membership status.
  - [ ] Integrate with payment processing for membership fees.
  - [ ] A system for manually upgrading/downgrading memberships by admins.
  - [ ] Invoice generation and history for membership payments.
- [ ] Custom domains for sites
- [ ] Pick from a set of domains we own
- [ ] Email notifications
  - [ ] Notify users of important account events (e.g., password changes, membership renewals).
  - [ ] Notify site owners of site-related events (e.g., new comments, site access requests).

### Lower priority

- [ ] Figure out a way to make the OCI image not run as root. Currently, the image runs as root which is not ideal for security. We need to create a non-root user and ensure the application can run with the necessary permissions.
- [ ] Need to get accurate dates for when sites were created and last accessed. The FedWiki farm API does not provide this info currently.
- [ ] Need better configuration handling. If you run the member-console with missing or invalid config, it just panics. We should validate the config and provide meaningful error messages.
- [ ] Currently, temporal schedules are created by the member-console on startup, when the member-console is deployed. When the member-console is redeployed, the old schedules are not removed, leading to weird behavior. We need a way to manage temporal schedules properly.
- [ ] Should session-secret and csrf-secret be generated on startup instead of in the config file? They should be persisted nonetheless. Do they need to be rotated?
- [ ] Add remove trailing slash middleware if we start using more custom handlers that don't end with a slash
- [ ] Add tests
  - [ ] CSRF
  - [ ] Logging
  - [ ] compression
  - [ ] recovery
  - [ ] request ID
  - [ ] timeout
  - [ ] secure headers and CORS
- [ ] Auth setup sanity check. Review code.
  - [ ] Remove keycloak specific code
  - [ ] Implement backchannel logout: When a user logs out of the application, the application should notify the identity provider to log the user out of the identity provider as well.
  - [ ] Auth session timeout should match security policy
  - [ ] Rate limiting on login attempts
  - [ ] Subresource Integrity (SRI) for CDN assets
- [ ] Serve HTMX assets not from CDN
- [ ] Find out if timeout middleware is actually needed or if net/http handles it
- [ ] Custom error pages
- [ ] ConnectAndMigrate should make a backup of the database before running migrations
- [ ] Centralize configuration management across services.
- [ ] Ensure proper use of context for request handling and database operations.
- [ ] I don't like the structure of internal/server/* files. HTMX handlers should be in their own files/folders.