Repository navigation
fix(fastify): read the session cookie on routes outside the plugin - #209
Merged
Merged
Conversation
The plugin registers @fastify/cookie in its own encapsulated scope, so an application route registered elsewhere has no request.cookies. requireAuth refused every cookie session there and getSeamlessUser found none, though the README offers both for exactly those routes. Both now parse the Cookie header themselves when nothing else did. getSeamlessUser in core also sends the token from the verified cookie when the caller passes no authorization, which is the case on any route the adapter's own hooks did not run on. Closes #207.
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.
Closes #207.
Why
The README offers
requireAuth(andgetSeamlessUser) for an application's own routes, withapp.get("/api/me", { preHandler: requireAuth(...) })as the example. With a cookie session that route answered 401.The plugin registers
@fastify/cookieinside its own encapsulated scope, sorequest.cookiesexists only on the plugin's routes. Two things went wrong elsewhere:requireAuthreadreq.cookies?.[cookieName], found nothing, and refused.getSeamlessUserfound no session either.Bearer tokens worked, which hid the problem from native clients. An adopter could not register
@fastify/cookieat the root to work around it, because the plugin registers it again and the two collide.This was found by the new adapter conformance suite (fells-code/seamless-cli#246). The Express reference app passed
GET /api/mewith a cookie session; the Fastify one answered 401.What changes
requestCookies(Fastify, internal). Returnsrequest.cookieswhen a cookie plugin parsed them, and otherwise parses theCookieheader with@fastify/cookie's ownparse.requireAuthandgetSeamlessUseruse it.getSeamlessUser(core). When the caller supplies noauthorization, it now sends the access token from the verified cookie.authorizationstill wins.The cookie is still verified against
cookieSecretbefore anything is read from it, and a forged cookie is still refused.Checks
pnpm test: core 403, express 210, fastify 160, nextjs 165, all passing.requireAuthon a root route next to the plugin accepts a cookie session, refuses a forged cookie, and refuses a request with noCookieheader.getSeamlessUserreads the cookie from the header.authorizationis given, and a caller'sauthorizationis preferred.Patch changeset for core, express and fastify.