Last modified: 2014-03-26 06:59:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T56512, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54512 - E:OpenID needs to work with $wgSecureLogin
E:OpenID needs to work with $wgSecureLogin
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
OpenID (Other open bugs)
master
All All
: Unprioritized normal (vote)
: ---
Assigned To: T. Gries
:
: 44353 (view as bug list)
Depends on:
Blocks: 9604
  Show dependency treegraph
 
Reported: 2013-09-24 16:19 UTC by Brad Jorsch
Modified: 2014-03-26 06:59 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brad Jorsch 2013-09-24 16:19:29 UTC
Special:OpenIDXRDS returns URLs based on $wgCanonicalServer. But when it attempts to redirect the user to these URLs, the forceHTTPS cookie kicks in and triggers a redirect to the corresponding https URL, which then fails due to loss of POST data.

Chris suggests this be worked around somehow in OpenID rather than having core use a 307 redirect instead of a 302.
Comment 1 Chris Steipp 2013-09-26 22:04:21 UTC
This is a problem with the id provider has $wgSecureLogin enabled. Since the WMF is running $wgSecureLogin, we need the extension to work with this in order to deploy it.
Comment 2 T. Gries 2013-10-03 08:11:10 UTC

*** This bug has been marked as a duplicate of bug 44353 ***
Comment 3 T. Gries 2013-10-03 14:07:57 UTC
*** Bug 44353 has been marked as a duplicate of this bug. ***
Comment 4 T. Gries 2013-10-03 14:09:10 UTC
perhaps better the other way around, you are right.

Can you help to fix it ?
Comment 5 Chris Steipp 2013-10-03 21:52:41 UTC
I tried to hack on it for a couple hours while reviewing it, and it's a difficult issue. But let me add what I know.

* Since it was mentioned above, 307 redirects don't seem to work in FF or Chrome for this, otherwise I'd be happy to do that in core. 

* The issue seems to be that when the consumer does the XRDS querries, the provider gives back http:// urls, even with wgSecureLogin enabled. When it's hacked to only return https:// something else in the Auth library is failing. When I return both, it will POST to the https url, but later it gives throws an exception about a missmatch in the urls.

But that's about as far as I was able to get. So it may be a fix inside of the library, or it might be a fix for the return of Special:OpenIDXRDS.
Comment 6 T. Gries 2013-10-03 21:59:59 UTC
(In reply to comment #5)
> difficult issue. But let me add what I know.
> 
> * Since it was mentioned above, 307 redirects don't seem to work in FF or
> Chrome for this, otherwise I'd be happy to do that in core. 
> 
> * The issue seems to be that when the consumer does the XRDS querries, the
> provider gives back http:// urls, even with wgSecureLogin enabled.
> ...

> But that's about as far as I was able to get. So it may be a fix inside of
> the library

This is also my view of the story. But my current thinking is, it _could_ be fixed in the library.



Only as a remark, not related to this bug:

I found - and fixed in E:OpenID - already at least one other issue with the library (the library does not return a correct return value for certificate errors)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links