Using Area 51 on Chrome with the HTTPS everywhere extension prevents successful login.

The error is:

The authentication URL, https://area51.stackexchange.com/... is different than the actual URL http://area51.stackexchange.com/

To login, I must disable the HTTPS everywhere extension.

Can you confirm this bug?


It's 2018 now, and all of Stack Exchange should be on HTTPS, even Area 51. But logging in to Area 51 using SE OpenID with HTTPS Everywhere is still broken, giving the following error:

Unable to log in with your OpenID provider:

The openid.return_to parameter (http://area51.stackexchange.com/users/authenticate/?s=11111111-1111-1111-1111-111111111111&dnoa.userSuppliedIdentifier=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000) does not match the actual URL (https://area51.stackexchange.com/users/authenticate/?s=11111111-1111-1111-1111-111111111111&dnoa.userSuppliedIdentifier=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.claimed_id=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.identity=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.sig=...) the request was made with.

(Remainder of the very long URL omitted; GUIDs anonymized, just in case.)

Without HTTPS Everywhere, logging in works, but takes a detour through an insecure HTTP URL:


It looks like the problem is that the Area 51 OpenID authentication code still sends a hardcoded http:// return URL to the provider, which then redirects back to it. With HTTPS Everywhere active, this return request gets rewritten to use HTTPS — but this means that the actual request URL no longer matches the signed copy of the openid.return_url parameter included with it. And the authentication code, observing that something fishy is going on, refuses to complete the login.

In principle, it should be possible to work around the error with an extra HTTPS Everywhere rule that would rewrite the return URL in the initial, unsigned request to the OpenID provider. But such a workaround would not solve the actual underlying problem, i.e. that without HTTPS Everywhere the login process here on Area 51 still goes through a non-HTTPS URL.

  • As of today, it works, so that issue seems to be fixed. – jknappen Feb 23 '18 at 17:32
  • I reported this to the HTTPS Everywhere folks and they added an exclusion rule to work around this, but the underlying issue (of Area 51 login going through an insecure HTTP URL) still exists. – Ilmari Karonen Mar 23 '18 at 1:27

I played around with it and there's no question but that HTTPS Everywhere breaks a ton of stuff on Area 51. But that's because we are still rolling out SSL support. Historically, when major changes are deployed, Area 51 is among the last subdomain to get updated. That's largely because Area 51 is running on an older version of the software. There's no guarantee that this bug will ever be fixed since:

  1. There's no particular reason to share sensitive data on this site, and
  2. We're unlikely to every make HTTPS default.

Sorry about that.

  • 2
    I just ran into this as well. Would love to see it fixed as it's a huge usability issue/bug. – Brad Bell May 30 '14 at 22:18
  • 5
    Thanks for responding! But this is actually a SERIOUS issue. The problem is that there IS sensitive data being transferred here - it's the LOGIN page that's broken! Plain text user credentials (SE email, real name(!!), and several other user id strings) and I THINK session cookies, are transferred on that page and a malicious sniffer (your ISP, a script kiddie on the airport's wifi, the NSA) can either steal, or modify them! Area51 is an important part of SE network -do you think you could contact a dev to have them look into this particular HTTPS bug? It's login page, it's a high-risk one :/. – user83826 Jan 10 '15 at 3:09
  • 2
    This is still happening, even though SSL support should have been deployed long ago. Looks like the SE OpenID login process here on Area 51 is still taking a detour through an insecure http: return URL, and forcing that URL to use HTTPS via HTTPS Everywhere breaks a security check somewhere. – Ilmari Karonen Jan 26 '18 at 20:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .