Rather than one lowest-common-denominator policy, each kind of route gets
the strictest policy it can bear: the server-rendered pages, the account
SPA shell, the Swagger UI, and a locked-down catch-all for everything
else. They are computed once at startup from the site configuration and
the `UrlBuilder` — the captcha provider origins, the plan-management
iframe origin and a possible cross-origin assets host are the only
dynamic inputs — and stored as prebuilt `HeaderValue`s.
The `form_post` authorization response is the one per-response case, as
its `form-action` names the redirect URI of the grant being completed.
The interactive playground page and its route/config option are gone; the GraphQL API itself (POST /graphql) is unaffected. External GraphQL usage is deprecated anyway in favour of the REST admin API.
Fixes#5572Fixes#2424
This makes it so that MAS binds on a temporary path on startup, sets
permissions and then moves it to the configured path. This means that we don't
error out anymore if there is a stale socket file, and that it is safe to
rollout a new process without killing the old one first, without breaking
connections.
When a browser signs out (or discovers its session was ended), the
session cookie now remembers when that happened; the flag is cleared by
the next successful login. The `additional_authorization_parameters`
templates can read it as `logged_out`, so operators can force a fresh
prompt at the upstream provider after sign-out, e.g.:
additional_authorization_parameters:
prompt: "{% if logged_out %}login{% endif %}"
This addresses the "sign out signs me back in" loop with upstream SSO
providers that still hold a live session.
Fixes#1569
branding.logo_uri was accepted and validated by the config layer but never
plumbed through to SiteConfig or any template, so it had no effect. Remove the
field and regenerate the committed config schema to remove the confusion.
This was done by auditing what's in the `mas-config` crate (and resulting
config JSON schema) and comparing it to the current configuration options
documentation.
Add a reference page describing the `http.server.response` log line and its
fields (method, status, requester, client address, GraphQL operation, request
id, trace id, …), aimed at administrators feeding the logs into a SIEM, with a
table of well-known operations and how to classify them (login, logout, token
issuance, …).
Updates the field doc-comment to describe the new templating semantics
and adds a deprecation note on `forward_login_hint` pointing to the
recommended replacement. Regenerates the JSON schema.
The runtime behavior (template rendering, forward_login_hint
soft-deprecation) is wired up in follow-up commits.
Quentin Gliech