This is a more of problem with services that change domains or session management so the advice here may actually help on other services also. We have seen this on many services and this is almost always the fix, including for us during the domain transition.
Due to how cookies on browsers are stored for sessions where 2 cookies with the same name can have different domain levels and values it’s easy in migrated services for a cookie to be created at some point where the session has a now invalid session cookie.
Sessions are usually stored in your browser using cookies, and they are stored based on a domain that is currently returning the request to your browser, but there is one type of cookie called a wild card. This is done a little different than a domain wild card and is formatted using an .
and not a *
like .nodehost.ca
in browsers.
This can cause a problem with a service as setting a cookie with the wild card and without will actually store it separate with the same name. For example if we have a wildcard and a dash specific one for the user session.
#Session Cookies
#Name - Value - Domain
SESID - jhu3oihfu8h3Ynh2 - .nodehost.ca
SESID - f32iuokyujn320sd - dash.nodehost.ca
In this example the cookie data and value sent to the dashboard would be both but with no understanding of what session is valid and good, and when it’s cleared the current used format may only be removed.
The fix, clear the cookies for the domain, if you know how to use inspector you can inspect the page go to Storage, Cookies and delete all current page cookies. This will force a new new session data to be created on page reload and you should be good.