Confirm login succeeds before the session disappears
Check whether the browser stores and returns the session cookie on the new HTTPS host before changing application login code.
A successful login response followed by an anonymous page may mean the new host never receives the session cookie. Confirm the canonical HTTPS host and whether the symptom occurs in a fresh private session, not just an old tab. Record the login response status and next request without copying the username, cookie value or session identifier. A redirect loop or rejected password is a different failure.
The application owner controls session configuration. Novasean hosting does not imply management of customer login code. Keep a rollback copy of the prior configuration and avoid changing all session settings at once.
Compare cookie attributes with the intended flow
In browser developer tools, inspect only the attributes of the application’s Set-Cookie response and whether the subsequent request includes that cookie; do not export or share its value. MDN documents Domain, Path, Secure and SameSite as controls on when a cookie is sent. A cookie scoped to the former hostname will not automatically travel to the new one; a path scoped too narrowly may miss the next page. A Secure cookie needs HTTPS, and SameSite affects cross-site flows. A browser may also reject a cookie for an invalid Domain attribute.
Check whether the application intended one host or a small set of related hosts. Do not broaden a session cookie to a parent domain simply to make login work; that can expose it to unrelated subdomains. If the flow crosses sites, map that journey before deciding whether SameSite=None; Secure is appropriate.
Change only the mismatched application setting
The application owner should correct the session cookie’s intended host, path or cross-site policy using the framework’s own configuration, and preserve Secure and HttpOnly where applicable. If a contracted proxy changes scheme or host information before the application generates the cookie, give the platform operator safe evidence of the mismatch for an in-scope review. Do not turn off HTTPS or weaken cookie protections as a generic workaround.
Test sign-in, sign-out and scope
In a fresh session on the canonical host, sign in, navigate to a second protected page and sign out. Confirm the browser sent the intended cookie only to expected host/path requests and that sign-out ends the session. If unrelated applications begin receiving it, revert the broadened scope immediately. If the cookie is sent correctly but the server still treats it as invalid, investigate session storage or application logic separately rather than widening attributes again.
For example, a successful login response followed by a request without the cookie points towards storage or scope, but inspect Secure and SameSite alongside Domain and Path before changing the session backend.
Frequently asked questions
Should I remove Secure because login fails? No. Check HTTPS and the application’s proxy awareness; removing transport protection is not a safe diagnosis.
Is a cookie issue the same as CORS? They can interact in cross-origin applications, but cookie storage and browser permission to read an API response are separate checks.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.