Pull Request Overview

This PR fixes login persistence when AUTH_SEND_JWT_HEADER is enabled by ensuring that the JWT token is stored in a client-side cookie and that the related XSRF token is extracted from the JWT and stored in its own cookie.

• Updated the documentation for the auth.send-jwt-header parameter to reflect the new behavior.
• Modified the fetcher.ts to persist the JWT token and extract the XSRF token from the JWT payload.
• Revised the server.go parameter description to clarify the behavior of sending the JWT header.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

Pull Request Overview

This PR improves login persistence when AUTH_SEND_JWT_HEADER is enabled by ensuring that JWT tokens received in headers are stored in client-side cookies and that the corresponding XSRF token is set accordingly.

• Updated documentation to clarify the behavior of AUTH_SEND_JWT_HEADER.
• Added logic in the frontend fetcher to parse and persist the JWT token and XSRF token via cookies.
• Expanded tests to verify cookie storage, Secure flag handling, error handling when setting cookies, and proper reset of in-memory tokens on 401/403 responses.
• Revised the backend flag description to match the new frontend behavior.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

Overview

PR #1929 implements a solution for login persistence when using AUTH_SEND_JWT_HEADER=true. The change stores JWT tokens received from server headers in client-side cookies, allowing login sessions to persist across page reloads.

Key Findings

Security Concerns

1. XSS Vulnerability Risk (High)
   - JWTs are stored in client-accessible cookies without HttpOnly flag
   - This makes tokens vulnerable to theft via XSS attacks
   - This is an inherent tradeoff with the AUTH_SEND_JWT_HEADER approach

2. Cookie Security Settings
   - ✅ SameSite=Strict is correctly used for CSRF mitigation
   - ✅ Secure flag is added for HTTPS connections
   - ❌ Missing __Host- prefix on cookies for additional security

3. CSRF Protection
   - ✅ JWT ID (jti) is extracted and used as XSRF token
   - ✅ Implementation follows Double Submit Cookie pattern

Code Quality

1. Hardcoded Values
   - 30-day cookie expiration is hardcoded (60*60*24*30)
   - This may not align with server-side JWT TTL configuration

2. Error Handling
   - ✅ Comprehensive try/catch blocks for token parsing and cookie setting
   - ✅ Errors are logged but silently fail for users

3. Documentation
   - ✅ Updated in server.go and parameters documentation
   - ❌ Missing explicit security warning about XSS risks

Recommendations

1. Security Enhancements
   - Add __Host- prefix to cookies when on HTTPS
   - Add explicit documentation warning about XSS risks
   - Consider aligning cookie expiration with JWT expiry

2. Code Improvements
   - Extract cookie setting to a helper function
   - Use a constant for the cookie expiration time
   - Use a more robust JWT parsing method that handles URL-safe base64

3. Cleanup Handling
   - Add explicit cookie cleanup on auth errors/logout

   This implementation provides the needed functionality, but the security tradeoffs should be clearly documented for users enabling this feature.