GITHUB_OAUTH_CALLBACK_URL's hardcoded default points at the frontend's port 3000, not the backend's 4000, in two places

Aperta Adatta ai principianti
#745 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

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

bug

Location

  • src/config/configuration.ts:90-92 — the github.oauthCallbackUrl default
  • src/auth/strategies/github.strategy.ts:19-21 — a second copy of the same default
  • src/config/configuration.ts:73-74 — appUrl / frontendUrl defaults, 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.example tells them to use) but they do not set GITHUB_OAUTH_CALLBACK_URL, Passport sends redirect_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/callback route, so the developer gets a 404 page, and AuthController.githubCallback never runs — no User row, 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_URL and FRONTEND_URL correctly 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

  1. Register a GitHub OAuth app with callback http://localhost:4000/api/auth/github/callback (as .env.example instructs).
  2. Set GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET but deliberately leave GITHUB_OAUTH_CALLBACK_URL unset.
  3. Start the backend (npm run start:dev, listening on 4000) and visit http://localhost:4000/api/auth/github.
  4. 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_uri on 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MergeFi/backend

Tutte le issue di MergeFi/backend

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.