3

I was trying to log into SEDE using the Stack Exchange OpenID function. However, without any erros, I kept not being logged in.

Eventually, I discovered I was using the HTTP to connect to SEDE, not HTTPS. After switching to HTTPS, the login worked.

Can you either fix this, move SEDE to HTTPS altogether, or at least show a descriptive error (perhaps block the login page on HTTP with an error?)

Browser: FF 60.0.2 x64 on Win 10.

Related: Is SEDE secure?


Edit: steps to reproduce:

On a clean Firefox (safe mode + private browsing), first, go to https://data.stackexchange.com. Log in succesfully. Now, open up a new tab to http://data.stackexchange.com. Try to log in. Doesn't work.

  • 1
    Well, question is how you got to the unsecure SEDE? All links I found on SE itself point to the secure version, as they should. If you have bookmarks, just update them. That's not very different from any other broken link. – Shadow Wizard Jun 10 '18 at 10:53
  • @ShadowWizard Typed in data in the address bar + autocomplete. I could purge it from my history, though. It's different imo because it doesn't show any errors, the only way to find out what's wrong is to look at your address bar and notice the lock missing (normally, on a broken link, you get a 404). – Erik A Jun 10 '18 at 10:57
  • 1
    Well, can't reproduce. Got a sock with SE OpenID too, but when logging in, the site itself redirects to https, and it works just fine. So it might be something on your side after all, e.g. browser plugin/addon. – Shadow Wizard Jun 10 '18 at 11:03
  • @ShadowWizard I can still repro this in Firefox safe mode, so it's not an add-on. The Log in using Stack Exchange redirects to data.stackexchange.com. No repro in Edge, though, it seems Firefox-specific, or it's related to login cookies that are already present maybe. – Erik A Jun 10 '18 at 11:07
  • Very weird, that's for sure. Since Firefox should be supported, hope someone with the power to fix will take a look soon then. – Shadow Wizard Jun 10 '18 at 11:08
  • 1
    I've added the steps to reproduce this. Apparently, it only occurs in Firefox and when you already have succesfully logged in over SSL. That makes the error a bit obscure, and I can understand the dev team not wanting to waste time on this. – Erik A Jun 10 '18 at 11:17
  • 1
    The problem is caused by the fact that you already got a .ASPXAUTH cookie that has its secure flag set (as it was delivered over HTTPS). When you then open a new tab and navigate to a plain http url you still get an .ASPXAUTH cookie send but as that would override the already present secure cookie Chrome and FF happily ignore that new cookie and rightfully so, I would say. Do note that going from plain http to https does work. – rene Jun 24 '18 at 10:14
  • 1
    A possible fix/hack for this could be to have different cookie names for the secure and insecure path and that could be possible added here github.com/StackExchange/StackExchange.DataExplorer/blob/master/… but that might break the http -> https transition. I currently don't have a setup handy where I can thoroughly test all these scenario's but I felt it might help to put this initial investigation out, to inspire others to come with ideas I might have overlooked – rene Jun 24 '18 at 10:18
  • Well, the different cookie names is out of the window as that would require redoing ASP.NET's form authentication. We might be able to store an extra session cookie to indicate we have successfully authenticated over HTTPS so that we can throw a warning when a user re-authenticates over http but the easiest is probably to just redirect everything to HTTPS so we don't have to deal with this split-brain extravaganza. I can't really judge if that has other consequences where I'm more concerned about load then anything else, as SEDE does work over a secure connection. – rene Jun 24 '18 at 18:01

You must log in to answer this question.

Browse other questions tagged .