Until now only the clippy CI job and the Dockerfile named a Rust version (kept in sync by hand), while every other CI job, the release binaries and the docs build ran on whatever `stable` happened to be that day. Rust 1.98.0 landing on 2026-08-20 broke `build-binaries` overnight because of that (#5935).
`rust-toolchain.toml` pins 1.96.0 with the `minimal` profile plus clippy, and every `rustup toolchain install stable ...` in CI becomes a bare `rustup toolchain install`, which reads the file. Starting at 1.96.0 (the version clippy is already clean against) keeps this change free of lint churn; catching up to 1.98.0 is a follow-up.
rustfmt stays on nightly because `.rustfmt.toml` uses nightly-only options, so that job now invokes `cargo +nightly fmt` explicitly instead of setting a rustup directory override, which would silently take precedence over the toolchain file.
The file does not list the linux cross-compilation targets on purpose: that would make every developer and CI job download `rust-std` they never use. The two consumers that cross-compile add the targets themselves.
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
Mechanical output changes from the dependency bump:
- aide 0.16 strips redundant null branches from optional query-param schemas
(optionality stays expressed via required:false on the parameter).
- schemars 1.0 changes doc-comment dedenting, emits the ClientsConfig newtype as
a named definition, and simplifies generic schema names
(e.g. JsonWebKeySet_for_JsonWebKeyPublicParameters -> JsonWebKeySet).
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, …).
Make `filter[client]` on `GET /api/admin/v1/oauth2-sessions` repeatable
so admin tooling can fetch sessions belonging to a set of clients in
one request. The field on `FilterParams` changes from `Option<Ulid>`
to `Vec<Ulid>`; the struct was already extracted with
`axum_extra::extract::Query` so the repeated values are not silently
dropped.
Each client ULID is validated to exist (mirroring the previous
single-client `404` behaviour) before being passed to the new
`OAuth2SessionFilter::for_clients` storage filter. The `Display`
impl used to reconstruct cursor links now emits one
`filter[client]=…` segment per client so pagination preserves the
filter. The OpenAPI schema is regenerated via `misc/update.sh` and
now describes the parameter as an array.
Quentin Gliech