Summary
Public-route knowledge is defined in two places that must be kept in sync manually:
JwtAuthModule.registerAsync({...}) in app.module.ts:
publicRoutes: ['/auth', '/api', '/docs', '/health'],
AppModule.configure():
consumer.apply(JwtAuthMiddleware).exclude(
{ path: 'auth/(.*)', method: RequestMethod.ALL },
{ path: 'api', method: RequestMethod.GET },
{ path: 'docs', method: RequestMethod.GET },
{ path: 'health', method: RequestMethod.GET },
)
The lists already disagree subtly: '/auth' (prefix string) vs 'auth/(.*)' (regex over subroutes). Adding a new public endpoint (e.g. a webhook receiver) requires editing both, and forgetting one yields confusing 401-vs-open inconsistencies.
Proposal
- Inspect
auth/middleware/jwt-auth.module.ts to determine which mechanism the middleware actually honors, then make that the single source of truth.
- Centralize the remaining list as a shared constant (e.g.
PUBLIC_ROUTES) consumed by configure().
- Add a unit test asserting matcher behavior for representative paths (
/auth/login, /health, /puzzles).
Acceptance criteria
Summary
Public-route knowledge is defined in two places that must be kept in sync manually:
JwtAuthModule.registerAsync({...})inapp.module.ts:AppModule.configure():The lists already disagree subtly:
'/auth'(prefix string) vs'auth/(.*)'(regex over subroutes). Adding a new public endpoint (e.g. a webhook receiver) requires editing both, and forgetting one yields confusing 401-vs-open inconsistencies.Proposal
auth/middleware/jwt-auth.module.tsto determine which mechanism the middleware actually honors, then make that the single source of truth.PUBLIC_ROUTES) consumed byconfigure()./auth/login,/health,/puzzles).Acceptance criteria