I've been conducting a systematic analysis of the new ChatPDF dashboard, specifically focusing on user authentication flow, as my team is considering its integration into our documentation pipeline. A recurring and critical failure mode has emerged: a persistent login loop following the recent UI update. After the initial credential submission, the user is redirected to what appears to be a successful authentication endpoint, only to be presented again with the login form, without any error message. This cycle repeats indefinitely.
From a pipeline and systems perspective, this suggests a breakdown in the session state management or a misconfiguration in the post-authentication redirect chain. To diagnose, I instrumented the browser's developer tools to monitor network traffic and local storage. The key observation is that while a session cookie (`chatpdf_session`) is set upon the POST to `/api/login`, a subsequent GET to `/dashboard` returns a 302 redirect *back* to `/login`. This indicates the backend is not validating the issued session token correctly for the new dashboard routes.
My hypothesis centers on two potential root causes, common in CI/CD deployment scenarios:
1. **Session Store Inconsistency:** The new dashboard service might be deployed to a different subdomain or path, and the session cookie's `Domain` or `Path` attributes are improperly scoped, causing the browser to fail to send it with the dashboard request.
2. **Cache Poisoning:** Aggressive static asset caching from a previous deployment (e.g., a stale `index.html` or service worker) could be serving old JavaScript that makes incorrect authentication checks.
A preliminary test to isolate the issue involves inspecting the exact cookie parameters and attempting access via an incognito window with all extensions disabled. Furthermore, the following `curl` command sequence can help verify the backend behavior independently of browser cache:
```bash
# Simulate login and capture cookie jar
curl -c cookies.txt -X POST -d "username=test&password=test" https://app.chatpdf.com/api/login
# Attempt to access dashboard with stored cookies
curl -b cookies.txt -v https://app.chatpdf.com/dashboard
```
The verbose output of the second command will show the HTTP response code and any `Location` header for the redirect. If this barebones request also loops, the issue is definitively server-side, likely in the routing logic or session middleware for the new dashboard component. I am interested if other users have encountered this and whether ChatPDF's engineering team has identified a specific deployment artifact or configuration change that correlates with the onset of this behavior.
Measure twice, cut once.
Your network trace analysis is solid, and your hypothesis about cookie path scope is almost certainly correct. I've seen this exact failure pattern when a deployment inadvertently creates a path mismatch between the auth service and the frontend routing.
A related, often-overlooked culprit can be the `SameSite` attribute on the session cookie. If it's set to `Strict` or `Lax` and the post-login redirect crosses a subdomain or port boundary (even from `app.chatpdf.com` to `dashboard.chatpdf.com`), the browser will drop the cookie, causing the loop. Check the `Set-Cookie` header details; you might need `SameSite=None; Secure` if they're using segmented architectures.