Page MenuHomePhabricator

Get OpenID extension to a state where it could be used on Wikimedia projects as a provider
Closed, DeclinedPublic

Description

Author: anon.hui

Description:
According to, T5060: Support OpenID Authentication within Mediawiki and T2057: Single login (Unified login) on all wikimedia projects, this extension would be great and help T2057 to be partially fixed.

OpenID is an distributed open Single-Sign-On System targeted on forums, wikis,
weblogs etc.

The extension is available at rEOID extension-OpenID

The documentation is at:
http://www.mediawiki.org/wiki/Extension:OpenID

See Also: T15631: Wikimedia should become an OpenID provider

Details

Reference
bz9604

Related Objects

StatusSubtypeAssignedTask
OpenFeatureNone
DeclinedFeatureNone
DeclinedNone
DeclinedWikinaut
DeclinedNone
DeclinedNone
Resolved brooke
ResolvedNone
ResolvedNone
ResolvedParent5446
ResolvedNone
ResolvedWikinaut
DeclinedNone
ResolvedNone
ResolvedWikinaut
ResolvedWikinaut
DeclinedNone
DeclinedBUG REPORTNone
ResolvedWikinaut
ResolvedWikinaut
ResolvedWikinaut
DeclinedWikinaut
DeclinedWikinaut
DeclinedFeatureNone
ResolvedWikinaut
InvalidWikinaut
InvalidWikinaut
ResolvedWikinaut
DeclinedNone
OpenNone
ResolvedTgr
ResolvedAnomie
ResolvedJoe
ResolvedJoe
Resolvedhashar
Resolvedbd808
ResolvedAnomie
ResolvedKrinkle
ResolvedNone
ResolvedJanZerebecki
ResolvedKrinkle
ResolvedTgr
ResolvedWikinaut
ResolvedWikinaut
ResolvedWikinaut
DeclinedNone
DeclinedNone
ResolvedWikinaut
DeclinedBUG REPORTNone
DeclinedNone
DeclinedFeatureNone
DeclinedNone
DeclinedFeatureNone
DeclinedNone
ResolvedWikinaut

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:39 PM
bzimport set Reference to bz9604.

ayg wrote:

My understanding is that this will be on the drawing board once the framework
for bug 57 is in place, and it will not be considered before then. Changing
dependency accordingly.

chtitux wrote:

Well, bug 57 seems unsolvable.
My idea of "How OpenID on Wikipedia should work" :

  • create a sub-domain for hosting OpenID accounts ( eg. id.wikimedia.org)
  • create your openID on id.WM.org
  • link your OpenID and your "local account" (double confirmation, with OpenID

and local accounts)

  • use your OpenID (where you have not a "local account") and your local account

(where you have one)

In fact, your unique OpenID and yours local accounts are attached.

mike.lifeguard+bugs wrote:

(In reply to comment #2)

Well, bug 57 seems unsolvable.
My idea of "How OpenID on Wikipedia should work" :

  • create a sub-domain for hosting OpenID accounts ( eg. id.wikimedia.org)
  • create your openID on id.WM.org
  • link your OpenID and your "local account" (double confirmation, with OpenID

and local accounts)

  • use your OpenID (where you have not a "local account") and your local account

(where you have one)

In fact, your unique OpenID and yours local accounts are attached.

Well, bug 57 has been solved now.

mike.lifeguard+bugs wrote:

Do we know if the code is ready for use?

Good question. I'd like to be able to use my WM identity elsewhere.

Added bug 17637 as dependency for this bug since for now OpenID extension only supports "FileStore" storage, which would need access through NFS.

remove shell keyword not ready for shell yet

ipatrol6010 wrote:

I would say this is good, but we shouldn't give full user privileges because we can't apply account creation blocks as effectively and, as our Wikipedia article says, there is a higher phishing risk. I would suggest limiting the privileges to user, non-autoconfirmed, and give them a username as idusername@providername. Full privileges simply require creating a local username and password.

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

For those who want to test, the present version in trunk (OpenID 0.929-beta) works *very* well. If someone gives me the possibility to install it on a WMF wiki, please let me know.

removed blocker. It does not "block" the Provider property.

(In reply to comment #8)

I would say this is good, but we shouldn't give full user privileges because we
can't apply account creation blocks as effectively and, as our Wikipedia
article says, there is a higher phishing risk. I would suggest limiting the
privileges to user, non-autoconfirmed, and give them a username as
idusername@providername. Full privileges simply require creating a local
username and password.

Are these limitations still applicable? If so why? (I cannot seem to find the article mentioned explaining why.)

There's currently a proposal on the English Wikipedia village pump to turn on OpenID. Is there any reason (technical or practical) that this wouldn't be feasible?

(In reply to comment #16)

There's currently a proposal on the English Wikipedia village pump to turn on
OpenID. Is there any reason (technical or practical) that this wouldn't be
feasible?

I am currently working on an improved version, so an implementation should wait until the new version is code reviewed and committed (perhaps in 2 weeks).

Also, there are a number of open bugs that make E:OpenID in its current form impossible to deploy functionally to WMF.

Does the village pump specify as a consumer or a provider? We'll need a designer to fix the UX issues to use it as a consumer. There's a number of bugs in the provider code, though Thomas is working on them.

Making this clearer per comments on bug 13631.

Qgil set Security to None.
Phabricator_maintenance renamed this task from Get OpenID extension to a state where it could be used on Wikimedia projects as a provider (tracking) to Get OpenID extension to a state where it could be used on Wikimedia projects as a provider.Aug 14 2016, 12:13 AM

Argh, that's posting about Phacility's Phabricator instance but being treated as ours.

nshahquinn subscribed.

If T15631: Wikimedia should become an OpenID provider is declined, there is no reason to develop the OpenID extension to support it. The extension also hasn't seen any real development in 9 years.