fix(proxy): pass DELETE /users/delete through so the SDK can delete an account - #167
Merged
Merged
Conversation
…n account The client SDK's deleteUser() has always sent DELETE /users/delete and the auth API has always served it, but neither adapter registered the route, so the call answered the adapter's own 404 through Express and the Fastify plugin alike. Nothing built on the SDK could delete an account, which both app stores require. Both adapters forward it with the caller's credential through a new core deleteAccountHandler. In cookie transport a successful deletion clears the access, refresh and pre-auth cookies the way /logout does, since the account they named no longer exists and the silent refresh would otherwise renew a session that is gone; a refused deletion leaves them alone. In bearer transport the auth API's body passes through and the client clears its own tokens. ensureCookies requires the access cookie on the route, and the parity suites hold both adapters to the same answer in both transports. Closes #166.
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.
Closes #166.
Summary
The client SDK's
deleteUser()sendsDELETE /users/delete, the auth API serves it onauth: 'access', and neither adapter registered it, so the call answered the adapter's own 404 in both transports. Both adapters now pass it through:packages/core/src/handlers/deleteAccount.ts:deleteAccountHandler, exported from the package. Forwards with the caller's credential; on success returns the auth API's body with the access, refresh and pre-auth cookies to clear (the same trio/logoutclears), on failure the upstream body throughreadUpstreamFailureand no cookie change.r.delete("/users/delete", ...)beside the logout routes, handler inpackages/express/src/handlers/deleteAccount.ts.authRoutes.tsbeside the logout loop.ensureCookies:/users/deleterequires the access cookie, like/users/update.Verification
pnpm build && pnpm test: core 305, express 186, fastify 103, all passing. New cases:usersRoutes.test.js: the route forwardsDELETE /users/deletewithAuthorization: Bearer <access>, answers the upstream body and clearsseamless-access,seamless-ephemeral,seamless-refresh; a 404 from upstream passes through with noSet-Cookie; no session means no upstream call.parity.test.js: "deleting the account clears every session cookie" holds both adapters to the same status, body and cookies.bearerTransport.parity.test.js: both adapters forward the bearer token and set no cookie.Found while building RoxTarget's account deletion (fells-code/roxtarget-web#8, fells-code/roxtarget-mobile#8), whose second half needs this release.