Status	Subtype	Assigned	Task
Open	Feature	None	T66475 Make crosswiki bits and pieces truly global (tracking)
Declined	Feature	None	T15631 Wikimedia should become an OpenID provider
Declined		None	T31254 [SUGGESTION] Expose group memberships for query through OpenID teams extension
Declined		Wikinaut	T25735 Allow different user grouping for OpenID users
Declined		None	T61631 Enable Facebook login on Wikimedia wikis
Declined		None	T11604 Get OpenID extension to a state where it could be used on Wikimedia projects as a provider
Resolved		Wikinaut	T46353 [SUGGESTION] Login page doesn't respect $wgSecureLogin

Event Timeline

• bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:40 AM

• bzimport added a project: MediaWiki-extensions-OpenID.

• bzimport set Reference to bz44353.

Parent5446 created this task.Jan 25 2013, 7:19 PM

(In reply to comment #0)

When $wgSecureLogin is set to true, the OpenID login page should redirect the
user to HTTPS so that all transactions occur over TLS.

@Tyler:

Isn't that a matter and task of the login code in MediaWiki core, which is now used from within OpenID ?

Perhaps, can you perform some tests with your local version, and let me know ?

I'm referring to how even when $wgSecureLogin is true, the Special:OpenIDLogin page (and the entire login process) still can take place over HTTP. Also, you can have HTTP providers even when $wgSecureLogin is enabled.

Bug 54512 has been marked as a duplicate of this bug. ***

Since bug 54512 has been marked as a duplicate of this, I'll note here that in addition to Special:OpenIDLogin the various URLs returned by Special:OpenIDXRDS also need to not fail if the forceHTTPS cookie might be set. See that bug for details.