github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 15:42:09 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[PR #8815] fix(oauth-provider): return JSON redirects from post-login OAuth continuation #16478

New Issue
Closed
opened 2026-04-13 10:32:13 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-13 10:32:13 -05:00
Owner
Copy Link

Original Pull Request: https://github.com/better-auth/better-auth/pull/8815

State: closed
Merged: Yes

Summary

Fixes #7041.
Closes #7280.

When authorizeEndpoint runs inside the OAuth after-hook (post sign-in), 2 bugs produce raw 302 redirects that browsers cannot follow under CORS constraints:

  • After-hook omission: the after-hook was the only authorizeEndpoint caller that did not signal a JSON-capable context. consent.ts and continue.ts already set Accept: application/json; the after-hook did not.
  • Error-path bypass: 11 early-validation branches in authorizeEndpoint threw ctx.redirect() directly, bypassing handleRedirect and its Sec-Fetch-Mode / Accept check. A client deleted or disabled between authorize and sign-in would always produce an unguarded 302.

The fix is scoped to 2 mechanisms:

  • Route every error redirect through handleRedirect, which returns JSON when the request is fetch-based and falls back to 302 for browser navigations.
  • Set Accept: application/json in the after-hook only when Sec-Fetch-Mode is not navigate, preserving 302 behavior for server-rendered form logins.
  • Add the same missing header in continue.ts:created(), matching the existing pattern in selected() and postLogin().

Summary by cubic

Fixes CORS failures after OAuth sign-in by returning JSON redirects for fetch-based flows while preserving 302 redirects for real navigations. Early error redirects now go through handleRedirect, and the post-login after-hook in oauth-provider sets Accept: application/json only for non-navigation requests.

  • Bug Fixes
    • Routed all early-validation redirects in authorizeEndpoint through handleRedirect to return JSON when appropriate.
    • In the after-hook (oauth.ts), detect navigations via Sec-Fetch-Mode: navigate or HTML Accept types (text/html, application/xhtml+xml); otherwise set Accept: application/json.
    • Added the missing Accept: application/json header in continue.ts:created() and expanded tests to cover continuation and post-login redirect behavior (JSON vs 302), including client deleted/disabled cases.

Written for commit 316c011c1e. Summary will update on new commits.

**Original Pull Request:** https://github.com/better-auth/better-auth/pull/8815 **State:** closed **Merged:** Yes --- ## Summary Fixes #7041. Closes #7280. When `authorizeEndpoint` runs inside the OAuth after-hook (post sign-in), 2 bugs produce raw 302 redirects that browsers cannot follow under CORS constraints: * **After-hook omission:** the after-hook was the only `authorizeEndpoint` caller that did not signal a JSON-capable context. `consent.ts` and `continue.ts` already set `Accept: application/json`; the after-hook did not. * **Error-path bypass:** 11 early-validation branches in `authorizeEndpoint` threw `ctx.redirect()` directly, bypassing `handleRedirect` and its `Sec-Fetch-Mode` / `Accept` check. A client deleted or disabled between authorize and sign-in would always produce an unguarded 302. The fix is scoped to 2 mechanisms: * Route every error redirect through `handleRedirect`, which returns JSON when the request is fetch-based and falls back to 302 for browser navigations. * Set `Accept: application/json` in the after-hook only when `Sec-Fetch-Mode` is not `navigate`, preserving 302 behavior for server-rendered form logins. * Add the same missing header in `continue.ts:created()`, matching the existing pattern in `selected()` and `postLogin()`. <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Fixes CORS failures after OAuth sign-in by returning JSON redirects for fetch-based flows while preserving 302 redirects for real navigations. Early error redirects now go through `handleRedirect`, and the post-login after-hook in `oauth-provider` sets `Accept: application/json` only for non-navigation requests. - **Bug Fixes** - Routed all early-validation redirects in `authorizeEndpoint` through `handleRedirect` to return JSON when appropriate. - In the after-hook (`oauth.ts`), detect navigations via `Sec-Fetch-Mode: navigate` or HTML `Accept` types (`text/html`, `application/xhtml+xml`); otherwise set `Accept: application/json`. - Added the missing `Accept: application/json` header in `continue.ts:created()` and expanded tests to cover continuation and post-login redirect behavior (JSON vs 302), including client deleted/disabled cases. <sup>Written for commit 316c011c1eb8cc72cd25b138e7097469069b912d. Summary will update on new commits.</sup> <!-- End of auto-generated description by cubic. -->
GiteaMirror added the pull-request label 2026-04-13 10:32:13 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#16478
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?