JBoss+Angular5环境下LSV Cookie请求中丢失问题咨询

Why Your LSV Cookie Is Missing in Subsequent Requests #

Let's break down the most probable causes based on your JBoss backend, Angular 5 frontend (with withCredentials = true), and the request/response details you shared:

1. Server Is Using the Wrong Header to Set Cookies #

Looking at your response headers, I spotted a critical issue: the server is returning a Cookie field instead of the standard Set-Cookie header to send cookie data to the browser.

Access-Control-Allow-Credentials: true ... Cookie: LSV=0; JSESSIONID=BPqD8YMn7q5IIgD5JomHPdnZVXxbC924UedeDqaB.xxx-sit-test02-p0 ...

Browsers only recognize the Set-Cookie response header to store or update cookies. Using Cookie in the response is invalid here—it's meant for requests to send cookies to the server. If the server isn't using Set-Cookie for LSV, the browser won't persist it correctly across requests, even if it appears in the initial request.

2. Missing Critical Cookie Attributes #

Even if Set-Cookie was used, omitting key attributes will lead the browser to apply restrictive defaults that can cause the cookie to not be sent in subsequent requests:

• Path: Without an explicit Path (e.g., Path=/), the browser will only send the cookie to the exact path of the initial request. For example, if LSV was set during a /login request, it won't be included in requests to /api/data.
• Domain: If the Domain attribute isn't set to match your frontend's origin (http://localhost or http://localhost:4200), the browser will restrict the cookie to the backend's domain only. Since your frontend runs on port 4200 and the backend on a different port, setting Domain=localhost ensures the cookie is sent across cross-origin requests.
• Max-Age/Expires: Without these, LSV is treated as a session cookie. While session cookies should persist until the browser closes, some edge cases (like page reloads with strict browser settings) can cause them to drop early.
• SameSite: If SameSite=Strict is set, the cookie won't be sent in cross-origin requests—even with withCredentials=true. Use SameSite=Lax or SameSite=None (with Secure if using HTTPS) for cross-origin scenarios.

3. Cross-Origin Configuration Mismatches #

Your response includes Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: http://localhost, but check for mismatches:

• Your frontend's referer is http://localhost:4200, but the allowed origin is http://localhost (without the port). Browsers treat different ports as separate origins, so the allowed origin should match exactly (including the port) to enable cookie transmission.
• Ensure Access-Control-Allow-Origin isn't set to * (it isn't in your case, but this is a common pitfall)—wildcards are incompatible with withCredentials=true.

4. Angular HTTP Client Configuration Issues #

Double-check that withCredentials = true is consistently applied across all requests:

• If using HTTP interceptors, make sure they aren't overriding or removing the withCredentials flag for subsequent requests.
• Verify no request-specific configurations are accidentally disabling withCredentials.

5. Browser-Specific Behavior or Settings #

• Incognito/Private Mode: Browsers often restrict cookie persistence more strictly in private windows—test in a regular window to rule this out.
• Third-Party Cookie Blocking: Even with same-domain setups, port differences might trigger third-party cookie rules in some browsers. Ensure your browser isn't blocking these.

内容的提问来源于stack exchange，提问作者Yong