Symptoms
- The app redirects back to login.
- A backend call returns unauthorized.
- A JSON-RPC call fails with a CSRF or session error.
- The user appears signed in but cannot access expected records.
- Sign-in hangs for a long time before completing.
- An expired password blocks sign-in.
Checks
- Confirm the backend is reachable.
- Confirm the frontend is pointed at the intended backend.
- Confirm the user is using the correct environment credentials.
- Refresh the CSRF token by loading the login page again.
- Confirm the user has access to the active company or tenant.
A session is restored, but a call was still refused
Darpan checks the session by asking the backend, and that check restores the session from the login cookie before answering. So a session probe can report a healthy, authenticated session about a call the backend has just refused. Read the failing call’s own response rather than the probe. An authorization refusal arrives as a normal HTTP 200 with an error in the JSON-RPC body — not as a 401 — so a check that only looks at HTTP status will report success on a refusal.Sign-in is slow rather than failing
A sign-in that eventually succeeds after a long pause is a different failure from one that is rejected quickly. A slow sign-in points at contention on the account record rather than at the credentials, and it affects everyone signing in against that record, not one person. A fast rejection points at the account state instead: an expired password, a required password change, or a disabled account. Darpan has a dedicated path for changing an expired password, so an expired credential is recoverable without an administrator resetting it.Sharing one account across several people makes the slow-sign-in case much more likely, and makes it look intermittent. Give each person their own account.
API testing shape
For API testing, authenticate against the assigned backend and send the session cookie plusX-CSRF-Token with /rpc/json. Use placeholder values only.