Repository navigation
fix: return 401 for expired or invalid tokens in authMiddleware - #216
Merged
TheCodeHeist-Coder merged 1 commit intoOct 26, 2026
Merged
TheCodeHeist-Coder merged 1 commit into
TheCodeHeist-Coder merged 1 commit into
Conversation
jwt.verify throws for expired, malformed and badly signed tokens, and the catch answered all of them with 500, so the client never logged the user out. Token errors (and a payload without userId) now get 401 and no stack trace in the logs. Anything else still returns 500. Adds a vitest setup to http-server with tests for the middleware, and a CI step to run them.
TheCodeHeist-Coder
approved these changes
Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
authMiddlewarewas answering everyjwt.verifyfailure with a 500, so an expired or garbage token never gave the client a 401 to log the user out on. Now expired, malformed and badly signed tokens, and a token whose payload has nouserId, get a 401. Any other error still returns 500. Theconsole.logstack trace no longer fires for those 401 cases.http-server had no test setup, so I added vitest the same way ws-server and streaming have it (
testscript, tests excluded from the tsc build) and a "Test http-server" step inci.yml. The new test file calls the middleware directly with a fake req/res and real signed tokens, so it needs no DB or services. It covers a valid token, expired token, garbage token, wrong secret, payload withoutuserId, and a non-token error still giving 500.Related issue
Closes #211
Type of change
Which services does this touch?
apps/frontendapps/http-serverapps/ws-serverapps/genAIpackages/db(schema or Prisma changes)How did you test this?
pnpm --filter http-server run test: 6 tests pass.userIdtests fail (they get 500), the valid token and non-token error tests pass.pnpm run check-typespasses.pnpm --filter http-server run build(tsc -b) passes, and the test file is not emitted intodist.pnpm install --frozen-lockfileworks with the lockfile change (only the vitest entry for http-server was added by hand topnpm-lock.yaml, to avoid pnpm rewriting unrelated entries).I did not run the app with docker-compose or hit a real endpoint with an expired token, only the unit tests above. I also did not run the full
pnpm run build, only the http-server build.pnpm run lintfails for me in the frontend with the existing eslint errors (CI hascontinue-on-errorfor it), and http-server has no lint script, so nothing in this change got linted.Checklist
pnpm run lintpnpm run check-typespnpm run builddocker-compose up.envfile, API key or other secretFirst pull request here? CONTRIBUTING.md walks through the
whole process, and a checkbox left unticked is not a problem — say so and we
will help.