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 for database migrations and 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

# 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/.

# 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.

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):

openssl rand -base64 32

Example output:

rJcniy2aWl3vwBcrMJfqsTL+Wys7EwDx/RC+DRrKcYg=

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

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:

• 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.