nextauthjs / nextauthjs/next-auth

Redirects require redundant setting of auth_url when using sveltekit for hosted apps

Open
#12,795 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug triage
Dominant language
TypeScript
Stars
28.4k
Forks
4k
PR merge metrics
No merged PRs in 30d

Description

Environment
System:
    OS: macOS 15.3.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 153.28 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.20.2 - ~/.nvm/versions/node/v18.20.2/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v18.20.2/bin/npm
  Browsers:
    Chrome: 134.0.6998.89
    Safari: 18.3
  npmPackages:
    @auth/core: ^0.37.4 => 0.37.4 
    @auth/drizzle-adapter: ^1.7.4 => 1.7.4 
    @auth/sveltekit: ^1.7.4 => 1.7.4 
Reproduction URL

https://github.com/megan-starr9/sveltekit-auth-example

Describe the issue

We have our sveltekit project hosted in AWS ECS currently. Everything works fine until we try to provide a redirect uri to our login components. Our host url winds up being our internal aws url, so we get the container's domain name being used instead of our actual site origin. (Ex: http://app-lb-#.us-west-2.elb.amazonaws.com rather than https://site-name.com)

This can be resolved if we utilize the AUTH_URL environment variable to set the correct domain. However, the sveltekit package sets the base url for us, resulting in the following warning spamming the logs.

[auth][warn][env-url-basepath-redundant] Read more: https://warnings.authjs.dev#env-url-basepath-redundant

This is an inconvenience and annoyance at worst, but it makes it extremely hard to parse through the logs and find actual valueable information when it comes up! So it would be greatly appreciated if this could be turned off for instances when we do want both values set to correct for origin behavior.

It appears that next-auth provides this ability within the core package
https://github.com/nextauthjs/next-auth/blob/5e07ca318ece5a97fd82df4aa93ea453ce8c5a60/packages/core/src/lib/utils/env.ts#L12
So a fix, it seems, would be as simple as allowing this value to be provided within our auth configuration when configuring our sveltekit auth preferences!

Alternatively, if this isn't a pattern that is seen as preferred, the ORIGIN environment variable should be used to configure redirect urls. Currently the behavior sets off of the internal host when an AUTH_URL is not present, which makes this environment variable more important than might be desired!

How to reproduce

Reproduction involves hosting your web application on an aws service behind a load balancer, which makes it a bit more difficult to provide!

Something similar could be achieved, maybe, by locally recreating a load balancer pattern. Essentially, the error only occurs when your application server's host does not match the desired domain name when using the sveltekit package.

Expected behavior

Users should be able to set the auth_url and the basepath. (Alternatively, the ORIGIN environment variable should be used when determining redirect urls when present)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked reproduction project and inspect packages/core/src/lib/utils/env.ts around the env-url-basepath-redundant handling. Compare that behavior with the SvelteKit configuration described in the issue; done means hosted redirects use the configured origin and base path without producing the redundant-setting warning.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
authentication, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.