chore(deps): move the API starters onto the adapters that forward the user agent - #88
Merged
Merged
Conversation
… user agent @seamless-auth/express 0.14.0 to 0.15.0 and @seamless-auth/fastify 0.5.0 to 0.6.0. Both now send the browser's User-Agent to the auth API as x-seamless-client-user-agent beside the client address they already forward, and pass GET /internal/metrics/sign-ins through. The auth API records a device class on every audit row from that header. A project on the older adapters has every row recorded as the adapter's own user agent, so the breakdown by device reads "unknown" for every sign-in. The starters needed the version and nothing else.
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
1 participant
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.
Last link in the fells-code/seamless-auth-api#154 chain: the API starters move onto the adapter releases that forward the browser's user agent (fells-code/seamless-auth-server#161), so applications generated from the next templates tag write a device class on every audit row.
What changed
@seamless-auth/express^0.14.0→^0.15.0and@seamless-auth/fastify^0.5.0→^0.6.0, with their lockfiles. Under 0.x a caret does not cross a minor, so an install alone would never have picked these up.Both adapters now send the browser's
User-Agentto the auth API asx-seamless-client-user-agentbeside the client address they already forward, and passGET /internal/metrics/sign-insthrough. The auth API (0.13.0) records a device class from that header on every audit row and reports sign-in outcomes by it, which the admin console's Overview reads. A project on the older adapters has every row recorded as the adapter's own user agent, so its breakdown by device readsunknownfor every sign-in; the other telemetry dimensions do not depend on the adapter.The starters needed the version and nothing else.
createSeamlessAuthServer,requireAuth,requireRoleandSeamlessAuthUserare unchanged, and nothing forwards anything a browser did not already send. The React starters stay on@seamless-auth/react0.12.0: the ephemeral token gained ajtithe client never reads. The lockfiles also pick up a transitivezod4.5.4 → 4.6.2 from@seamless-auth/core.Verification
npm run check(typecheck, lint, format:check, test) andnpm run buildclean in bothtemplates/api/expressandtemplates/api/fastifynpm run validateandnpm run format:checkat the root cleanminorchangeset, as the previous adapter bump (chore(deps): move the starters onto the session-gated enrolment release #86) wasAfter this
Merging the version PR this produces cuts the tag
seamless-clipins and seamless-idea-api builds its runtime image from (SEAMLESS_TEMPLATES_REF), which is what actually puts the new adapter in front of the fleet.