Feat/server tests#7
Conversation
| session({ | ||
| secret: 'test-secret', | ||
| resave: false, | ||
| saveUninitialized: false, | ||
| }) |
Check warning
Code scanning / CodeQL
Clear text transmission of sensitive cookie Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 months ago
In general, to fix this class of issues with express-session, you should explicitly configure the cookie option to ensure that sensitive cookies are marked as secure (sent only over HTTPS) and httpOnly (inaccessible to client-side scripts). Relying on defaults (secure: 'auto') can be brittle, especially behind proxies or in nonstandard environments.
For this specific file, the best fix is to modify the session({...}) call inside createApp to include an explicit cookie configuration, e.g. cookie: { secure: true, httpOnly: true }. This makes the intent clear and ensures that, in any environment where HTTPS is available, the cookie is not sent over cleartext. Since this is test code and we are not allowed to change other parts of the project, we should avoid adding environment-dependent logic here and just configure the cookie securely. The change is localized to server/routes/auth.test.ts, lines 28–32, and does not alter any test behavior beyond tightening cookie flags on the created session cookie; Supertest-based tests that only inspect HTTP responses will continue to work.
Concretely:
- Edit the
sessionoptions object increateAppto add acookieproperty withsecure: trueandhttpOnly: true. - No new imports are needed because
cookieis just a plain object property on theexpress-sessionoptions. - No other files or lines need to be updated.
| @@ -29,6 +29,10 @@ | ||
| secret: 'test-secret', | ||
| resave: false, | ||
| saveUninitialized: false, | ||
| cookie: { | ||
| secure: true, | ||
| httpOnly: true, | ||
| }, | ||
| }) | ||
| ); | ||
| app.use(checkUser); |
624bfa4 to
e1159ff
Compare
5d835b7 to
5ff31a2
Compare
f9cbd97 to
7ecb018
Compare
TypeORM represents the 'date' column type (date only) as a string, not a JS date object. This was causing the reset password expiration check to never activate, since it compares the date (which is a string) with new Date(), which is always truthy.
7ecb018 to
eed3103
Compare
Description
How Has This Been Tested?
Screenshots / Logs (if applicable)
Checklist:
pnpm buildpnpm i18n:extract