chore: bump to auth API v0.13.1, dashboard v0.7.0 and templates v0.14.0 - #201
Merged
Conversation
SEAMLESS_AUTH_API_VERSION v0.12.0 to v0.13.1, SEAMLESS_AUTH_ADMIN_DASHBOARD_VERSION v0.6.0 to v0.7.0, SEAMLESS_TEMPLATES_REF v0.13.0 to v0.14.0, and the conformance harness adapters to @seamless-auth/express ^0.15.0 and @seamless-auth/fastify ^0.6.0. API 0.13.0 records a deployment id, device class, mail provider, owner flag and attempt id on every audit row and adds the funnel and sign-ins metrics routes; 0.13.1 is the same server on a release image that applies Debian security updates, since 0.13.0 never published one. Dashboard 0.7.0 reads both routes on its Overview, so the standalone console pin moves with the API image, which serves the same dashboard at /console. Templates 0.14.0 carries the adapters that forward the browser user agent, which the device class depends on; its manifest contract and registry are byte-identical to 0.13.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SEAMLESS_AUTH_API_VERSIONSEAMLESS_AUTH_ADMIN_DASHBOARD_VERSIONSEAMLESS_TEMPLATES_REF@seamless-auth/express(verify adapter)@seamless-auth/fastify(verify adapter)Closes the loop on fells-code/seamless-auth-api#154: a project scaffolded from this release runs the instrumented auth server behind an adapter that gives it what the instrumentation needs, and serves a console that shows the result.
Auth API
v0.13.0records five dimensions on everyauth_eventsrow at write time: a deployment id (APP_ID), a device class folded from the user agent, the subject's mail provider (a provider name, never the domain), an owner flag againstOWNER_EMAIL, and the attempt the row belongs to (the ephemeral token's newjti). It addsGET /internal/metrics/funnel(time to registration, time to login, passkey adoption) andGET /internal/metrics/sign-ins(outcomes per method, device class, mail provider and owner flag, and where attempts stop), and honoursx-seamless-client-user-agentfrom a trusted adapter.v0.13.1is the same server on a release image that applies Debian security updates at build time;v0.13.0never published an image because its scan failed on a base-imagepcre2finding, which is why the pin skips it..env.exampleis byte-identical between v0.12.0 and v0.13.1, so no new scaffold environment keys arrive with this.Admin dashboard
v0.7.0adds a Passwordless Funnel section and a Sign-in Outcomes section to Overview, reading the two routes above. The API image ships that dashboard at/console, so the standalone console pin (--admin=image,--admin=source) moves with it and both admin modes serve the same release. Against an older API the two new sections report themselves unavailable in place; the rest of the screen is unaffected.Templates and adapters
Templates
v0.14.0carries@seamless-auth/express0.15.0and@seamless-auth/fastify0.6.0in the API starters, and the conformance harness's adapters take the same^0.15.0/^0.6.0. Those adapters forward the browser'sUser-Agentto the API beside the client address they already forward, and pass the sign-ins route through. The adapter is the only client the API sees, so a project on the older adapters has every audit row recorded as the adapter's own user agent and its breakdown by device readsunknown; the other four dimensions do not depend on the adapter. The templates diff between v0.13.0 and v0.14.0 is those two pins and their lockfiles; the manifest contract and the registry are byte-identical, so nothing ininitmoves with the ref. The React starters stay on@seamless-auth/react0.12.0, since the token claim the API added is one the client never reads.Verification
npm run buildclean;npm test: 53 files, 1001 passingscripts/scaffold-smoke.shrun locally against this branch (withSMOKE_EXTRA_COMPOSEunpublishing the ports, since 5432 and 5312 are taken here): it pulledghcr.io/fells-code/seamless-auth-api:v0.13.1, broughtdbandauthup, wrote a row, recreated the container and read it back.PASS.https://raw.githubusercontent.com/fells-code/seamless-auth-api/v0.13.1/.env.example(whatinitfetches) answers 200.ghcr.io/fells-code/seamless-auth-admin-dashboard:v0.7.0exists; templates tagv0.14.0exists.minorchangeset, as chore: bump to auth API v0.12.0, dashboard v0.6.0, templates v0.13.0 #200 was.