Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

break free of NEXTAUTH_URL using http header #4556

Closed
wants to merge 7 commits into from

Conversation

devinrhode2
Copy link

We need to support multiple domain names pointing to the same next.js server (multi-tenancy). Other parts of our infrastructure will pass an X-Forwarded-Host header to this next.js server, which we need to use in place of the NEXTAUTH_URL.

This is just a hack to get working for our use case.
I noticed the version:pr npm script might actually publish this PR as a package, which is what I am trying to do by opening this PR. If it doesn't publish a package, then I will close and re-open later once this is ready for review

I tried using patch-package but was getting this Can't find lockfile entry for next-auth error :/

馃Б Checklist

  • Documentation
  • Tests
  • Ready to be merged

馃帿 Affected issues

#600

馃搶 Resources

add NEXTAUTH_TRUST_X_FORWARDED_HOST to types
add TRUST_HOST_HEADER to types

patch `throw string` (to throw new Error(string)
goal was to get auth working with X-Forwarded-Host instead of NEXTAUTH_URL.

Plenty of work should be done to this more "merge-able" into the public github project:
- Make a nice alternative api to NEXTAUTH_URL
  - Maybe there is no "api", we just keep using X-Forwarded-Host as we are now
- Be backwards compatible
  - If NEXTAUTH_URL, it should be used, to be backward compatible.
  - If you don't have NEXTAUTH_TRUST_X_FORWARDED_HOST or VERCEL set,
    then NEXTAUTH_URL could be defaulted to `localhost:3000` was before,
    except this time we explicitly default it in one place.
@vercel
Copy link

vercel bot commented May 13, 2022

The latest updates on your projects. Learn more about Vercel for Git 鈫楋笌

1 Ignored Deployment
Name Status Preview Updated
next-auth 猬滐笍 Ignored (Inspect) May 13, 2022 at 4:27AM (UTC)

@github-actions github-actions bot added client Client related code core Refers to `@auth/core` labels May 13, 2022
Copy link
Collaborator

@ubbe-xyz ubbe-xyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time to open a PR 鈽曪笍

This is just a hack to get working for our use case.

Can you close this PR and open an issue explaining the problem and the proposed solution in-depth? We can then define how the API is going to look there 馃憤馃徑

@ubbe-xyz ubbe-xyz self-assigned this May 14, 2022
@devinrhode2
Copy link
Author

I linked to issue #600 in the Affected Issues section

@ubbe-xyz
Copy link
Collaborator

ubbe-xyz commented May 17, 2022

@devinrhode2 So the core team is considering adding a config option to allow trusting certain headers (which will solve your issue and part of #600).

We don't have a timeline for this yet (we have many fronts open); we have to be very clear about the messaging and call it an advanced option because it has serious security implications.

We'll update on this in #600, for now, I suggest the best is to close this PR and we'll take it as a reference when working on the solution 馃摍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client Client related code core Refers to `@auth/core`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants