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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#745 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
85/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
authentication, backend

Línea de trabajo

Lee src/config/configuration.ts y src/auth/strategies/github.strategy.ts para rastrear los valores predeterminados de la URL de callback. Después, comprueba la ruta registrada por AuthController y las pruebas de configuración existentes. Actualiza los valores predeterminados para que el callback siga APP_URL y haya una única fuente de verdad; añade el caso propuesto a configuration.spec.ts. El trabajo estará terminado cuando el callback predeterminado use el origen del backend y la prueba lo confirme.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
90
Merge medio
31 min
PR fusionados (30 d)
20

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MergeFi/backend

Todos los issues de MergeFi/backend

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.