github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-08-31 12:32:52 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #7807] /oauth2/continue endpoint returns uri instead of url, breaking client-side redirects #28237

New Issue
Closed
opened 2026-04-17 19:41:28 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-17 19:41:28 -05:00
Owner
Copy Link
Copy Source

Originally created by @DibyodyutiMondal on GitHub (Feb 5, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7807

Originally assigned to: @bytaesu on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. create a setup with the new oauth-provider package
  2. add signup.page and signup.shouldRedirect option, and always return true for shouldRedirect (for simulation)
  3. on the client-side, handle the signup.page url, and call the continue endpoint through better-auth client. you will notice that you will not automatically redirect

Current vs. Expected behavior

current behaviour: the continue endpoint returns a response which we have to handle inside an if check and assign to window.location

expectation: the redirect should be handled seamlessly inside better-auth.

example: /sign-in/email inside an oauth flow automatically handles redirect even if it returns json

What version of Better Auth are you using?

1.5.0-beta.9

System info

{
  "system": {
    "platform": "linux",
    "arch": "x64",
    "version": "#1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025",
    "release": "6.6.87.2-microsoft-standard-WSL2",
    "cpuCount": 16,
    "cpuModel": "Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz",
    "totalMemory": "31.34 GB",
    "freeMemory": "10.01 GB"
  },
  "node": {
    "version": "v24.5.0",
    "env": "development"
  },
  "packageManager": {
    "name": "pnpm",
    "version": "10.28.1"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "~16.0.6"
    },
    {
      "name": "react",
      "version": "19.2.0"
    },
    {
      "name": "fastify",
      "version": "5.6.2"
    }
  ],
  "databases": [
    {
      "name": "mongodb",
      "version": "7.0.0"
    }
  ],
  "betterAuth": {
    "version": "1.5.0-beta.9",
    "config": null
  }
}

Which area(s) are affected? (Select all that apply)

Package, Client, Backend

Auth config (if applicable)

Additional context

the client-side redirectPlugin in packages/better-auth/src/client/fetch-plugins.ts expects url:

  if (context.data?.url && context.data?.redirect) {
      window.location.href = context.data.url;
  }
Originally created by @DibyodyutiMondal on GitHub (Feb 5, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7807 Originally assigned to: @bytaesu on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. create a setup with the new oauth-provider package 2. add signup.page and signup.shouldRedirect option, and always return true for shouldRedirect (for simulation) 3. on the client-side, handle the signup.page url, and call the continue endpoint through better-auth client. you will notice that you will not automatically redirect ### Current vs. Expected behavior current behaviour: the continue endpoint returns a response which we have to handle inside an if check and assign to window.location expectation: the redirect should be handled seamlessly inside better-auth. example: /sign-in/email inside an oauth flow automatically handles redirect even if it returns json ### What version of Better Auth are you using? 1.5.0-beta.9 ### System info ```bash { "system": { "platform": "linux", "arch": "x64", "version": "#1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025", "release": "6.6.87.2-microsoft-standard-WSL2", "cpuCount": 16, "cpuModel": "Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz", "totalMemory": "31.34 GB", "freeMemory": "10.01 GB" }, "node": { "version": "v24.5.0", "env": "development" }, "packageManager": { "name": "pnpm", "version": "10.28.1" }, "frameworks": [ { "name": "next", "version": "~16.0.6" }, { "name": "react", "version": "19.2.0" }, { "name": "fastify", "version": "5.6.2" } ], "databases": [ { "name": "mongodb", "version": "7.0.0" } ], "betterAuth": { "version": "1.5.0-beta.9", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Package, Client, Backend ### Auth config (if applicable) ```typescript ``` ### Additional context the client-side redirectPlugin in `packages/better-auth/src/client/fetch-plugins.ts` expects url: ```ts if (context.data?.url && context.data?.redirect) { window.location.href = context.data.url; } ```
GiteaMirror added the lockedbug labels 2026-04-17 19:41:28 -05:00
GiteaMirror commented 2026-04-17 19:41:29 -05:00
Author
Owner
Copy Link
Copy Source

@better-auth-agent[bot] commented on GitHub (Feb 5, 2026):

It seems that the issue with the /oauth2/continue endpoint returning a uri instead of a url is related to the expectations set in your code for handling redirects. Currently, the implementation in fetch-plugins.ts expects context.data.url to perform the redirect seamlessly, but your endpoint is not fulfilling that expectation.

To address this, consider updating the endpoint to ensure it sends back a url in the appropriate format for handling redirects, similar to behavior seen in the /sign-in/email flow. This way, you should be able to achieve the seamless redirect you expect.

If you are looking for an immediate workaround, you might need to manually handle the redirect on the client side by checking the response and setting window.location.href based on the uri returned, until this is resolved in the endpoint's implementation.

For further assistance or to raise more detailed inquiries about the issue, I'd recommend tagging members of the Better Auth team like @bekacru or @ping__.

Do you have any existing implementations or other questions around using the Better Auth framework that you’d like to discuss?

If you need more help, tag @better-auth-agent in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3854419986 --> @better-auth-agent[bot] commented on GitHub (Feb 5, 2026): It seems that the issue with the `/oauth2/continue` endpoint returning a `uri` instead of a `url` is related to the expectations set in your code for handling redirects. Currently, the implementation in `fetch-plugins.ts` expects `context.data.url` to perform the redirect seamlessly, but your endpoint is not fulfilling that expectation. To address this, consider updating the endpoint to ensure it sends back a `url` in the appropriate format for handling redirects, similar to behavior seen in the `/sign-in/email` flow. This way, you should be able to achieve the seamless redirect you expect. If you are looking for an immediate workaround, you might need to manually handle the redirect on the client side by checking the response and setting `window.location.href` based on the `uri` returned, until this is resolved in the endpoint's implementation. For further assistance or to raise more detailed inquiries about the issue, I'd recommend tagging members of the Better Auth team like @bekacru or @ping__. Do you have any existing implementations or other questions around using the Better Auth framework that you’d like to discuss? _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-17 19:41:29 -05:00
Author
Owner
Copy Link
Copy Source

@DibyodyutiMondal commented on GitHub (Feb 5, 2026):

@better-auth-agent

it's not 'my' endpoint, it's the continueEndpoint that is part of the oauth-provider package

<!-- gh-comment-id:3854459210 --> @DibyodyutiMondal commented on GitHub (Feb 5, 2026): @better-auth-agent it's not 'my' endpoint, it's the continueEndpoint that is part of the oauth-provider package
GiteaMirror commented 2026-04-17 19:41:30 -05:00
Author
Owner
Copy Link
Copy Source

@better-auth-agent[bot] commented on GitHub (Feb 5, 2026):

It seems that your issue pertains to the /oauth2/continue endpoint returning a uri instead of a url, which is affecting client-side redirects in your OAuth flow. This endpoint is indeed part of the oauth-provider package, and the expected behavior would ideally handle the redirect seamlessly without needing to manually assign the response to window.location.

To troubleshoot this:

  1. Ensure that the client-side code correctly checks the response structure. Currently, it seems you're relying on a conditional check to handle the redirect.
  2. You might consider looking into the redirectPlugin in the fetch-plugins.ts, which is expected to handle the url redirect. The behavior you observed indicates a discrepancy in how the continue endpoint is returning the response.

Additionally, you can report this issue to the Better Auth team on GitHub if it persists, as it might be a bug that needs addressing in future updates.

Lastly, please tag the Better Auth team members @bekacru or @ping__ if you require further assistance or specific guidance.

What does your current implementation look like for handling this redirect? Have you tried logging the response from the continue endpoint?

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3854460835 --> @better-auth-agent[bot] commented on GitHub (Feb 5, 2026): It seems that your issue pertains to the `/oauth2/continue` endpoint returning a `uri` instead of a `url`, which is affecting client-side redirects in your OAuth flow. This endpoint is indeed part of the oauth-provider package, and the expected behavior would ideally handle the redirect seamlessly without needing to manually assign the response to `window.location`. To troubleshoot this: 1. Ensure that the client-side code correctly checks the response structure. Currently, it seems you're relying on a conditional check to handle the redirect. 2. You might consider looking into the `redirectPlugin` in the `fetch-plugins.ts`, which is expected to handle the `url` redirect. The behavior you observed indicates a discrepancy in how the `continue` endpoint is returning the response. Additionally, you can report this issue to the Better Auth team on GitHub if it persists, as it might be a bug that needs addressing in future updates. Lastly, please tag the Better Auth team members @bekacru or @ping__ if you require further assistance or specific guidance. What does your current implementation look like for handling this redirect? Have you tried logging the response from the `continue` endpoint? <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-17 19:41:30 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Feb 5, 2026):

Hi @DibyodyutiMondal, I'm checking this

<!-- gh-comment-id:3855488373 --> @bytaesu commented on GitHub (Feb 5, 2026): Hi @DibyodyutiMondal, I'm checking this
GiteaMirror commented 2026-04-17 19:41:30 -05:00
Author
Owner
Copy Link
Copy Source

@DibyodyutiMondal commented on GitHub (Feb 7, 2026):

May be worth adding a TODO in the comments so that we remove support for "uri" in a later major version, in order to encourage consistency across the ecosystem

<!-- gh-comment-id:3865748336 --> @DibyodyutiMondal commented on GitHub (Feb 7, 2026): May be worth adding a TODO in the comments so that we remove support for "uri" in a later major version, in order to encourage consistency across the ecosystem
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 labels bug locked
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#28237