GITHUB_OAUTH_CALLBACK_URL's hardcoded default points at the frontend's port 3000, not the backend's 4000, in two places
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 85/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- node.js, typescript
- Ambito
- authentication, backend
Direzione di ricerca
Leggi src/config/configuration.ts e src/auth/strategies/github.strategy.ts per ricostruire i valori predefiniti dell’URL di callback. Poi controlla la route registrata da AuthController e i test di configurazione esistenti. Aggiorna i valori predefiniti affinché il callback segua APP_URL e ci sia un’unica fonte di verità; aggiungi il caso proposto a configuration.spec.ts. Il lavoro è completato quando il callback predefinito usa l’origine del backend e il test lo conferma.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Location
src/config/configuration.ts:90-92— thegithub.oauthCallbackUrldefaultsrc/auth/strategies/github.strategy.ts:19-21— a second copy of the same defaultsrc/config/configuration.ts:73-74—appUrl/frontendUrldefaults, for contrast.env.example:34— the documented value
Problem
The config factory defaults the OAuth callback to the frontend's origin:
appUrl: process.env.APP_URL ?? 'http://localhost:4000', // backend
frontendUrl: process.env.FRONTEND_URL ?? 'http://localhost:3000', // Next.js
...
oauthCallbackUrl:
process.env.GITHUB_OAUTH_CALLBACK_URL ||
'http://localhost:3000/api/auth/github/callback', // :3000, not :4000
GET /api/auth/github/callback is a backend route (AuthController.githubCallback, served under the api global prefix set at main.ts:42), and the backend listens on port — default 4000. The default callback therefore names a path that exists on the backend, on the origin of the frontend.
.env.example:34 has the correct value (http://localhost:4000/api/auth/github/callback), which confirms :3000 is a mistake rather than an intentional proxy arrangement — and it means the two sources of truth for the same setting disagree.
The wrong literal appears twice: once in configuration.ts and again as the strategy's own fallback at github.strategy.ts:19-21, so fixing only the config file leaves the second copy to take over whenever githubConfig?.oauthCallbackUrl is falsy.
Why it matters
OAuth redirect URIs are matched exactly by the provider. The callback URL has to agree in three places — the GitHub OAuth app registration, the value Passport sends as redirect_uri on the authorize request, and the route that actually handles the redirect. This default breaks that agreement in the one scenario the defaults exist for: a developer running the stack without setting the variable.
What a new contributor following the README experiences:
- If their GitHub OAuth app is registered with
http://localhost:4000/api/auth/github/callback(the value.env.exampletells them to use) but they do not setGITHUB_OAUTH_CALLBACK_URL, Passport sendsredirect_uri=http://localhost:3000/..., and GitHub refuses the authorize request outright with "The redirect_uri MUST match the registered callback URL for this application". Login never starts. - If they instead register
http://localhost:3000/...to match the default, GitHub accepts the handshake and sends the browser to the Next.js dev server with?code=<github-oauth-code>. Next.js has no/api/auth/github/callbackroute, so the developer gets a 404 page, andAuthController.githubCallbacknever runs — noUserrow, no JWT, no cookie. The failure looks like a frontend routing problem, which is a long way from the real cause. - In either case the GitHub authorization code is delivered to the wrong origin. For a local dev setup that is merely confusing; for anyone who copies this pattern into a deployed environment (setting
APP_URLandFRONTEND_URLcorrectly but leaving the callback unset), the authorization code is handed to the public frontend origin instead of the backend that holds the client secret.
The duplicated literal makes this harder to notice than it should be: grep GITHUB_OAUTH_CALLBACK_URL finds the config entry, and a reader who fixes it there will not realise the strategy still carries its own copy.
Reproduction / failure path
- Register a GitHub OAuth app with callback
http://localhost:4000/api/auth/github/callback(as.env.exampleinstructs). - Set
GITHUB_CLIENT_IDandGITHUB_CLIENT_SECRETbut deliberately leaveGITHUB_OAUTH_CALLBACK_URLunset. - Start the backend (
npm run start:dev, listening on 4000) and visithttp://localhost:4000/api/auth/github. - Observed: the browser is sent to
https://github.com/login/oauth/authorize?...&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fgithub%2Fcallback, and GitHub responds with a redirect_uri mismatch error. Expected:redirect_urion port 4000, matching the registration and the route that serves it.
Suggested fix
Derive the default from appUrl so it can never drift from the port the backend actually listens on:
const appUrl = process.env.APP_URL ?? 'http://localhost:4000';
...
oauthCallbackUrl:
process.env.GITHUB_OAUTH_CALLBACK_URL ?? `${appUrl}/api/auth/github/callback`,
That also keeps the default correct when PORT/APP_URL are changed, which a hardcoded literal cannot.
Remove the duplicate fallback at src/auth/strategies/github.strategy.ts:19-21 entirely and read the configured value directly — a single source of truth. (The same file's clientId/clientSecret fallbacks have their own problem; see the separate issue about the dead production boot guard.)
Add a configuration.spec.ts case asserting that with APP_URL set and GITHUB_OAUTH_CALLBACK_URL unset, github.oauthCallbackUrl is rooted at APP_URL — and that the resulting path matches the route AuthController actually registers.
- Lingua principale
- TypeScript
- Stelle
- 2
- Fork
- 90
- Merge medio
- 31m
- PR unite (30g)
- 20
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MergeFi/backend
-
bug security
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
bug testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
bug security
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di MergeFi/backend
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
zapcooking/frontend#946 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
WiliamRosa/cosmos-semantic-platform#40 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
liberation-data/drivine#733 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
makecindy/cindy#10062 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno