Login succeeds then sends you back to the login page? Read the session cookie the browser actually keeps

Start with what the browser did, not what the server meant

A login loop has two halves. The server decides you are signed in and tells the browser to store a cookie. The browser then decides whether to keep that cookie and whether to send it back on the next request. The server cannot see the browser's decision, so server logs that say login succeeded prove nothing about the second half. The quickest evidence is in the browser developer tools: log in once with a test account, open the Network tab, select the response that sets the cookie and read the Cookies view. A cookie the browser rejected is normally flagged with a warning there. Then check whether the very next request carries it.

Do not copy the cookie value anywhere. The attributes are what you need.

• Is a cookie set at all in the login response?
• Does the browser store it? Look at the Application or Storage view.
• Is it sent on the next request to the signed-in page?

The five attributes that decide it

Secure: the cookie is sent only over HTTPS, apart from localhost, and an insecure page cannot set one. A site that sets Secure while the browser reached it over plain HTTP, or whose app believes it is on HTTP, loses the cookie. SameSite: Lax sends the cookie on top-level navigations with a safe method but not on cross-site subrequests or POSTs; None sends it everywhere but must be combined with Secure; Strict sends it only for same-site requests. Domain: when omitted the cookie is host-only and returns only to the host that set it; when set it covers that domain and its subdomains. Path: the cookie is sent only where the request path matches, so a cookie set with a narrow path vanishes elsewhere. Expiry: a cookie with neither Expires nor Max-Age is a session cookie and is removed when the browser closes, although session-restore features may bring it back.

• Symptom only on the live domain: check Secure and the forwarded protocol.
• Symptom only when arriving from another site or an email link: check SameSite.
• Symptom only on one subdomain: check Domain.
• Symptom only on some pages: check Path.
• Symptom after restart: check Expires and Max-Age.

Alternative explanations

If a cookie is set and sent but the app still shows the login page, the cause is on the server: a session store that is in memory on one instance while requests reach another, a secret that differs between instances so cookies cannot be read, or a session that was created and then replaced because the app issued a new identifier after login and lost the old state. Issuing a new session identifier after login is recommended by OWASP; the fault is losing the state, not issuing the identifier. Clock differences can also matter: Expires is relative to the server clock, although MDN notes that Firefox and Chromium adjust for skew using the Date header.

• Two or more app instances: do they share one session store and one secret?
• Cookie set twice with different attributes, one overriding the other?
• A proxy or content network stripping or rewriting Set-Cookie?

What fixes it, and what does not fit

Change only the attribute proven to be the cause, and keep the cookie as protected as the journey allows. OWASP recommends Secure, HttpOnly and an explicit SameSite value, an unset Domain, and the narrowest Path that works, and the __Host- prefix for session identifiers where it fits. Turning Secure or SameSite off to make the loop disappear trades the symptom for a weaker cookie. A problem that appears before the user reaches your app, such as a provider error, is a different fault, and so is a wrong password.

• A fix that removes protection is a workaround, not a repair.
• A shared login across different registrable domains needs a design decision and is outside a single-journey repair.

How the paid job is accepted

Our login-session repair (posted test price from £295, untested, quoted after we read your description and set-up) is accepted when a test user stays signed in across ten page loads in each agreed environment (and across a browser restart where a lasting session is agreed in writing), is signed out on logout, and the cookie shows the agreed attributes with the value removed. You keep the proxy and host settings and the merge decision; where the cause is a host setting only your team can change, we give the exact steps. Send the two addresses, your hosting set-up and what the user sees, not passwords or cookie values.