Rewrite Auth Subsystem because Chrome doesn't delete session cookies

[freestylecoder]

We have a lot of problems / complaints that the submission site doesn't work on Chrome (ya know, no big deal. It's only the most popular browser.) Turns out, it's a "feature" (read: bug) in Chrome that it doesn't delete session cookies if you have "On Startup: Continue where you left off" selected, which, oh, by the way, is the default setting.

So, there is no fix for this on our side. If we use the same auth system, the fix is to tell the user to either A) use an Incognito tab or B) Change the setting in Chrome.

Since that's not really an option, the real fix is to completely find a way to re-write the auth system to not use session cookies. Granted, I wanted to rewrite the auth system, anyway. Of course, the new system would have still used session cookies, just would have it OAuth to other sites (I want to get out of the password business...)

I'm open to ideas.

[dannagle]

Add a timestamp to the session storage. If you don't get a hit on that session after a couple hours, invalidate the session.

[freestylecoder]

I do that. That's the probem in our code. The expire time is stored with the session in the DB. The root of the problem is that Chrome submits the session id, which the DB sees as expired. There is code in there that sould tell it to ignore that fact. Basically, if you see an expired session token, don't reject at the handler level. Instead, pass it, unauthenticated, down the chain and let the REST function reject it.

That should be ok, because the Login handlers should reset it to a valid value. It also appears that Chrome isn't letting me change the value of the session cookie.

[dannagle]

The client itself could also detect expired session and redirect itself to the logout page.

[freestylecoder]

It does, if not cookie exists. Every other browser does it correctly.

[dannagle]

Add a secondary check beyond just "not exist". Many servers use a crontab to clear stale sessions. Have you tried that?

[freestylecoder]

Been doing so digging, and I can't recreate this in the debugger with Chrome on Windows. It overwrites the old session with the new session every time, no matter what crazy stuff I try to do...

[freestylecoder]

Currently can't replicate on Chrome for MacOS, either

[dannagle]

Maybe a Chrome add-on or weird config outside the default is messing things up. Maybe it is an old version. Or perhaps a sync between different Chromes messes it up.

You should be able to invalidate all sessions at will regardless of what Chrome says. TCP can disconnect uncleanly at any moment. I think a crontab is the way to go. I've been using that method for years without issues. As a bonus, you can have the crontab do other work.

[freestylecoder]

That wouldn't fix the problem (as I understand it.) I've never seen it let an expired session through. It's somehow getting past the login screen, which resets the session correctly. I wonder if it's a caching issue. The profile page redirects you to login if you attempt to get the profile of someone that is not you. However, we're getting 401 errors, not 400.

[dannagle]

Yes, that sounds like a cache problem. Unfortunately, there is little you can do to the server to fix this. Even if you timestamp inside the headers, the browser will probably ignore the timestamp and cache anyway.

Here is another idea: Make the JavaScript poll the server. Try something like this...

window.setInterval(pollValid, 3000);

function pollValid()
{
   if(sessionNotValid()) {
       window.location.href = "/?logout=true";   //Expired! Redirect user.
   }
}

[ProfessorTom]

Is this issue still relevant?

[freestylecoder]

Oh yeah. It's still the BIGGEST issue with the site.