Files

T

cgalo5758 0b28a9dc29 Remediate security audit findings

- Replace gorilla/csrf with net/http CrossOriginProtection
- Require valkey-password and add TLS options for session store
- End session at /logout and revoke refresh tokens
- Re-derive identity and roles from provider every five minutes
- Process each Stripe webhook event in its own Temporal workflow
- Give each outbox entry its own workflow with Temporal retries
- Guard against stale Stripe events with provider timestamps
- Derive transport security from base-url scheme

2026-09-09 13:25:43 -05:00

2.1 KiB

Raw Blame History

console-init Specification

Purpose

TBD - created by archiving change member-console-init-scaffold. Update Purpose after archive.

Requirements

Requirement: `init` scaffolds a usable starter config

member-console init <path> SHALL write a starter mc-config.yaml to the target directory composed of the embedded core configuration template (embeds.Config) plus one generated section per registered integration that declares configuration (config.ConfigProvider), not a placeholder stub. The scaffolded file SHALL be valid YAML containing every configuration key that member-console start requires, with commented placeholder values the operator fills in. Each generated integration section SHALL list that integration's ConfigSpec keys as commented lines carrying the key's usage text, its default when one is declared, and a file-based alternative note for secret keys. The embedded core template SHALL NOT hand-list keys that an integration's ConfigSpec declares. The template's OIDC issuer example SHALL reference a dedicated application realm placeholder, never an administration realm such as Keycloak's master.

Scenario: init writes the embedded starter template

WHEN an operator runs member-console init ./my-instance
THEN ./my-instance/mc-config.yaml SHALL be created from the embedded template
AND it SHALL parse as YAML and contain the required keys (base-url, db-dsn, valkey-addr, valkey-password, oidc-idp-issuer-url, oidc-sp-client-id)

Scenario: Every declaring integration appears in the scaffold

WHEN the scaffolded config is inspected
THEN it SHALL contain one commented section per registered integration that declares configuration, including every key from that integration's ConfigSpec
AND no registered declaring integration SHALL be absent

Scenario: Integration sections are generated, not hand-maintained

WHEN a new integration registering a ConfigSpec is added to the integration registry
THEN init's scaffold SHALL include its section with no change to the embedded template or init code

2.1 KiB Raw Blame History