Context
fells-code/seamless-auth-server#103 (closing fells-code/seamless-auth-server#96 and fells-code/seamless-auth-server#97) removes GET /auth/magic-link from the Express adapter and replaces it with POST /auth/magic-link.
GET /magic-link was a state-changing simple request. Combined with the SameSite=None cookie default and no CSRF or Origin check, an <img src="https://api.example.com/auth/magic-link"> on any page triggered unbounded magic-link emails to the victim.
Impact on this SDK
One call site breaks:
src/client/createSeamlessAuthClient.ts around line 527:
requestMagicLink: () =>
requestResult<MessageResult>(
fetchWithAuth(`/magic-link`, { method: 'GET' }),
'Failed to send the magic link.'
),
method: 'GET' becomes 'POST'. Against an adapter carrying fells-code/seamless-auth-server#103, the current code gets a 404 and magic-link login stops working.
Explicitly not affected
Verified against the rest of the client, so these need no change:
logout and logoutAllSessions already use DELETE /logout and DELETE /logout/all. The removal of GET /logout does not touch them.
checkMagicLink (GET /magic-link/check) is unchanged in the adapter.
verifyMagicLink (GET /magic-link/verify/:token) is unchanged. It stays GET on purpose: the token in the path is the credential and it arrives from an email link.
Downstream consumers (seamless-portal, seamless-review-web, seamless-templates) all call authClient.requestMagicLink() rather than hitting the route directly, so fixing it here covers them. They will each need a version bump.
Work
Ordering
Land fells-code/seamless-auth-server#103 first. This change is incompatible with adapter versions before it, so the two releases need sequencing rather than shipping in parallel.
Context
fells-code/seamless-auth-server#103 (closing fells-code/seamless-auth-server#96 and fells-code/seamless-auth-server#97) removes
GET /auth/magic-linkfrom the Express adapter and replaces it withPOST /auth/magic-link.GET /magic-linkwas a state-changing simple request. Combined with theSameSite=Nonecookie default and no CSRF or Origin check, an<img src="https://api.example.com/auth/magic-link">on any page triggered unbounded magic-link emails to the victim.Impact on this SDK
One call site breaks:
src/client/createSeamlessAuthClient.tsaround line 527:method: 'GET'becomes'POST'. Against an adapter carrying fells-code/seamless-auth-server#103, the current code gets a 404 and magic-link login stops working.Explicitly not affected
Verified against the rest of the client, so these need no change:
logoutandlogoutAllSessionsalready useDELETE /logoutandDELETE /logout/all. The removal ofGET /logoutdoes not touch them.checkMagicLink(GET /magic-link/check) is unchanged in the adapter.verifyMagicLink(GET /magic-link/verify/:token) is unchanged. It stays GET on purpose: the token in the path is the credential and it arrives from an email link.Downstream consumers (
seamless-portal,seamless-review-web,seamless-templates) all callauthClient.requestMagicLink()rather than hitting the route directly, so fixing it here covers them. They will each need a version bump.Work
createSeamlessAuthClient.ts.method: 'GET'for that call (tests/createSeamlessAuthClient.test.ts, and checktests/login.test.tsx).Ordering
Land fells-code/seamless-auth-server#103 first. This change is incompatible with adapter versions before it, so the two releases need sequencing rather than shipping in parallel.