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

[GH-ISSUE #4815] Inconsistent use of baseURL vs productionURL in oauth-proxy plugin #10082

New Issue
Closed
opened 2026-04-13 05:59:57 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-13 05:59:57 -05:00
Owner
Copy Link

Originally created by @jens-kuerten on GitHub (Sep 22, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4815

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Configure the oauth-proxy like this:

betterAuth({
  baseURL: "https://myapp.com",          // (main) app domain
  trustedOrigins: ["https://myapp.com","https://*.myapp.com"]
  plugins: [
    oAuthProxy({
      productionURL: "https://login.myapp.com",  // OAuth redirect domain
    }),
  ],
});

Deploy the app on a VPS and point multiple domains at the app. (myapp.com, login.myapp.com, tenant1.myapp.com, etc..)

  • If you log in with Google at tenant1.myapp.com, the user is redirected back to tenant1.myapp.com correctly. ✅

  • If you log in at myapp.com, the user ends up at login.myapp.com instead of myapp.com. ❌

Current vs. Expected behavior

Current behavior:
When baseURL and productionURL differ, the oauth-proxy plugin behaves inconsistently in a multi-domain setup.

When a user starts on baseURL (myapp.com), they will be redirect to productionURL (login.myapp.com) after login instead of staying on myapp.com.

If a user starts on any other url (e.g. tenant1.myapp.com) the redirect after login works correctly.

Expected behavior:
The user is always redirected back to the domain they started on, even if that domain is baseURL and differs from the productionURL.

What version of Better Auth are you using?

1.3.9

System info

{
  "system": {
    "platform": "linux",
    "arch": "x64",
    "version": "#1 SMP Tue Nov 5 00:21:55 UTC 2024",
    "release": "5.15.167.4-microsoft-standard-WSL2",
    "cpuCount": 16,
    "cpuModel": "AMD Ryzen 7 8845HS w/ Radeon 780M Graphics",
    "totalMemory": "46.71 GB",
    "freeMemory": "36.12 GB"
  },
  "node": {
    "version": "v22.15.0",
    "env": "development"
  },
  "packageManager": {
    "name": "pnpm",
    "version": "10.15.0"
  },
  "frameworks": [
    {
      "name": "react",
      "version": "^19.1.1"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "kysely",
      "version": "^0.28.7"
    }
  ],
  "betterAuth": {
    "version": "^1.3.7 < 1.3.8 || ^1.3.9",
    "config": null
  }
}

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

Backend

Auth config (if applicable)

Additional context

This might be a use-cases that wasn't considered for the plugin, which is probably why this issue exists.

I have one application server (running in docker on a VPS) that serves multiple domains: one main domain (myapp.com) and several sub-domains (tenant1.myapp.com, tenant2.myapp.com, etc.). I am using the oauth-proxy, to enable each tenant to login, while only having to register one oauth callback (login.myapp.com).

Suggested fix: update the after hook condition to check productionURL || baseURL (consistent with the before hook).

- if (origin === getOrigin(ctx.context.baseURL)) {
+ const productionURL = opts?.productionURL || env.BETTER_AUTH_URL || ctx.context.baseURL;
+ if (origin === getOrigin(productionURL)) {
Originally created by @jens-kuerten on GitHub (Sep 22, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4815 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Configure the oauth-proxy like this: ``` betterAuth({ baseURL: "https://myapp.com", // (main) app domain trustedOrigins: ["https://myapp.com","https://*.myapp.com"] plugins: [ oAuthProxy({ productionURL: "https://login.myapp.com", // OAuth redirect domain }), ], }); ``` Deploy the app on a VPS and point multiple domains at the app. (myapp.com, login.myapp.com, tenant1.myapp.com, etc..) - If you log in with Google at tenant1.myapp.com, the user is redirected back to tenant1.myapp.com correctly. ✅ - If you log in at myapp.com, the user ends up at login.myapp.com instead of myapp.com. ❌ ### Current vs. Expected behavior **Current behavior:** When baseURL and productionURL differ, the oauth-proxy plugin behaves inconsistently in a multi-domain setup. When a user starts on baseURL (myapp.com), they will be redirect to productionURL (login.myapp.com) after login instead of staying on myapp.com. If a user starts on any other url (e.g. tenant1.myapp.com) the redirect after login works correctly. **Expected behavior:** The user is always redirected back to the domain they started on, even if that domain is baseURL and differs from the productionURL. ### What version of Better Auth are you using? 1.3.9 ### System info ```bash { "system": { "platform": "linux", "arch": "x64", "version": "#1 SMP Tue Nov 5 00:21:55 UTC 2024", "release": "5.15.167.4-microsoft-standard-WSL2", "cpuCount": 16, "cpuModel": "AMD Ryzen 7 8845HS w/ Radeon 780M Graphics", "totalMemory": "46.71 GB", "freeMemory": "36.12 GB" }, "node": { "version": "v22.15.0", "env": "development" }, "packageManager": { "name": "pnpm", "version": "10.15.0" }, "frameworks": [ { "name": "react", "version": "^19.1.1" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "kysely", "version": "^0.28.7" } ], "betterAuth": { "version": "^1.3.7 < 1.3.8 || ^1.3.9", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript ``` ### Additional context This might be a use-cases that wasn't considered for the plugin, which is probably why this issue exists. I have one application server (running in docker on a VPS) that serves multiple domains: one main domain (myapp.com) and several sub-domains (tenant1.myapp.com, tenant2.myapp.com, etc.). I am using the oauth-proxy, to enable each tenant to login, while only having to register one oauth callback (login.myapp.com). Suggested fix: update the after hook condition to check productionURL || baseURL (consistent with the before hook). ``` - if (origin === getOrigin(ctx.context.baseURL)) { + const productionURL = opts?.productionURL || env.BETTER_AUTH_URL || ctx.context.baseURL; + if (origin === getOrigin(productionURL)) { ```
GiteaMirror added the lockedbug labels 2026-04-13 05:59:57 -05:00
GiteaMirror commented 2026-04-13 05:59:58 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 22, 2025):

Hi @jens-kuerten! I'm Dosu and I’m helping the better-auth team.

You've correctly identified a bug in the oauth-proxy plugin: the after hook only checks if the redirect origin matches baseURL, while the before hook uses productionURL (or falls back to baseURL). This mismatch causes users who start on baseURL to be redirected to productionURL after login, instead of returning to where they started. The suggested fix—updating the after hook to check productionURL || baseURL—matches the logic in the before hook and would resolve the inconsistency in multi-domain setups. You can safely patch your deployment with this change until an official update is released. No recent pull requests or documentation address this issue yet, so your workaround is the best approach for now. For reference, see the relevant plugin code.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3319282011 --> @dosubot[bot] commented on GitHub (Sep 22, 2025): <!-- Greeting --> Hi @jens-kuerten! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> You've correctly identified a bug in the oauth-proxy plugin: the after hook only checks if the redirect origin matches `baseURL`, while the before hook uses `productionURL` (or falls back to `baseURL`). This mismatch causes users who start on `baseURL` to be redirected to `productionURL` after login, instead of returning to where they started. The suggested fix—updating the after hook to check `productionURL || baseURL`—matches the logic in the before hook and would resolve the inconsistency in multi-domain setups. You can safely patch your deployment with this change until an official update is released. No recent pull requests or documentation address this issue yet, so your workaround is the best approach for now. For reference, see the relevant [plugin code](https://github.com/better-auth/better-auth/blob/1baaccbf52803d27046dce3da57c5c7201a020fb/packages/better-auth/src/plugins/oauth-proxy/index.ts). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a506fb7c-ac5a-4d63-84e9-aae58e6b6606?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4815)
GiteaMirror commented 2026-04-13 05:59:59 -05:00
Author
Owner
Copy Link

@nehaaprasad commented on GitHub (Sep 22, 2025):

@jens-kuerten
i think users now go back to the domain they started from after login
please let me know!

<!-- gh-comment-id:3320039221 --> @nehaaprasad commented on GitHub (Sep 22, 2025): @jens-kuerten i think users now go back to the domain they started from after login please let me know!
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 bug locked
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#10082
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?