43

I can't seem to log in with my Stack Exchange OpenID. When I try, I get the error message:

Unable to log in with your OpenID provider:

The openid.return_to parameter (https://unix.stackexchange.com/users/authenticate/?s=......) does not match the actual URL (https://unix.stackexchange.com/users/authenticate/?s=......) the request was made with.

It works if I disable the HTTPS-Everywhere plugin in Firefox, but if I then re-enable the plugin and go to a site on which I am not logged in (in which case login is normally nearly seamless), it fails again with the same error message, or at least something very similar.

I'm not aware of having done anything that might have caused this, although I will admit I don't recall seeing https:// in the address bar on Stack Exchange before (I do now, and that's a good thing IMO!). I was using the site a few hours ago and it worked fine then, but not now...

Improve this question
9
  • HTTPS isn't fully supported yet, so it seems the server-side code doesn't take the client scheme into consideration when setting up the initial OpenID request.
    – Tim Stone
    Commented Jan 5, 2014 at 0:51
  • 2
    @TimStone Um, it seems to me no matter how you slice it that question is about half a year old (and the actual question is over two years old). Why would Stack Exchange have worked just fine for me earlier today, and failed now, with no client-side changes in the interim?
    – user
    Commented Jan 5, 2014 at 0:54
  • 1
    I assume your HTTPS Everywhere plugin didn't start pointing you to the HTTPS version of Stack Exchange sites until recently. The authentication is making a faulty assumption that you're always using HTTP right now, but I'm not sure if that will be fixed until HTTPS is actually officially supported.
    – Tim Stone
    Commented Jan 5, 2014 at 0:57
  • 2
    Was just having the same problem and could not figure out why it was happening. Glad I found this post because it saved me some time.
    – user176495
    Commented Jan 5, 2014 at 5:27
  • 5
    Same here, it was working just fine until today, and have been using HTTPS everywhere for ages.
    – Mark Mayo
    Commented Jan 5, 2014 at 6:03
  • Just add that the issue is in Chrome also. I've been using HTTPS everywhere without issue but I just opened a new incognito tab and it replicated.
    – Manetheran
    Commented Jan 5, 2014 at 6:38
  • 4
    Obviously there was an upate of HTTPS everywhere two days ago where according to permalink.gmane.org/gmane.comp.mozilla.firefox.https-everywhere/… the rulesets for stackexchange sites have been changed.
    – Benedikt Bauer
    Commented Jan 6, 2014 at 16:17
  • 2
    Sorry about this. We generally do more testing in the development branch before merging changes to an important rule like Stack-Exchange into the stable branch, but this was an exception because SSL support for stackexchange was blocking the launch of tor.stackexchange.com.
    – Yan Z
    Commented Apr 5, 2014 at 0:01
  • Now that HTTPS support has been implemented across the site, should this be marked [status-complete]?
    – Stevoisiak
    Commented Jul 31, 2017 at 14:55

2 Answers 2

Reset to default
38

I can't say I found out exactly what is wrong, but I think I've found out how to fix the immediate error.

  1. Go into the HTTPS Everywhere "Enable / Disable Rules" dialog (in Firefox, this is done through Tools -> HTTPS Everywhere -> Enable / Disable Rules; apparently, in Chrome you click the blue HTTPS Everywhere plugin icon in the URL bar - thanks Matt).
  2. Type 'stack' into the search box, or just navigate through the list manually. Locate the "Stack Exchange (mixed content)" rule.
  3. Click the green checkmark next to it. This turns it into a red X, indicating that the rule has been disabled.
  4. Click OK.

Depending on what exactly you do on the network you may also need to disable the "Stack Exchange (partial)" rule, but it looks like that isn't necessary for me.

After performing the above steps, you should be able to log in just fine, albeit apparently without automatic HTTPS.

A more proper fix would be to server-side check whether the request is coming in over HTTP or HTTPS, and set the return URL accordingly. However, that is obviously outside of the ability of us mere mortals.

It would seem like HTTPS Everywhere downloads (and downloaded) new rules automatically, and someone didn't test the Stack Exchange ruleset thoroughly before pushing it into everyone's installation. The kind of scary part is that I can't see any way to disable this behavior or even to be notified when the rules are automatically updated.

Improve this answer
4
  • 3
    Yish ... so even custom rules are overwritten when the mother ship updates? Yuckyuckyuckyuck.
    – user50049
    Commented Jan 8, 2014 at 9:06
  • 4
    @TimPost updates rules can be suggested via a pull request on the github repo, so if somebody from SE knows where https does and doesn't work on the site, they could submit a patch.
    – nhinkle
    Commented Jan 9, 2014 at 3:10
  • I recommend clearing the browser's history so you don't accidentally go back to the https version of the site.
    – Celeritas
    Commented Jan 21, 2014 at 3:01
  • @TimPost We don't override custom preferences when we ship an update. Changelogs and other docs are all up at eff.org/https-everywhere. You can join the mailing list ([email protected]) to get updates when I release a new addon version!
    – Yan Z
    Commented Apr 4, 2014 at 23:58
9

I'm the primary maintainer of HTTPS Everywhere. Just pushed a fix for this that should be out in the next release: https://github.com/EFForg/https-everywhere/commit/ed9e6622b00f91bf695dfe2c7d8bf066791b142c

(You can use it now if you build your own .xpi/.crx using the instructions in the README.)

Note that this is just a hack; really, the fix is for StackExchange to add the SSL version to the OpenID parameter. Hopefully full SSL support is coming soon.

Improve this answer
3

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