Greetings,
Very soon (maybe this afternoon), I'd like to submit a patch to add OpenID login support to MediaWiki. Dan Libby has already contributed such a patch:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3060
Our patch (JanRain, Inc.) is a patch against CVS HEAD, extends Dan Libby's original modifications, and uses the PHP OpenID library that we built and maintain at
http://www.openidenabled.com/openid/libraries/php/
Here are some notes from the openid.txt file included in the patch:
- OpenID support works in *addition* to normal wiki logins, including any external authentication plugin configured by the MediaWiki administrator. If a username looks like a URL, OpenID auth is tried; otherwise, the regular authentication rules apply.
- If OpenID support cannot be verified (either because the library is missing or because the store directory can't be initialized -- see step (3) in Installation), MediaWiki will function normally even if $wgUseOpenID is set to true.
- The account creation form cannot currently be used to create accounts with OpenID identity URLs. If you want to create an account with your OpenID, just log in. The account will be created automatically.
Any thoughts or concerns? I'm busy preparing some things and then I'll attach a .diff to the bug ticket above.
Lastly, provided that the patch is accepted at some point, I'll be happy to be active in supporting and maintaining OpenID support in MediaWiki.
Thanks!
I assume that does OpenID, LID and YADIS given the development you guys have been doing on those areas?
Is it just Relying Party support, or does it also enable registered Wikipedia users to use their Wikipedia identity with other places?
On Jan 30, 2006, at 16:02, Jonathan Daugherty wrote:
Greetings,
Very soon (maybe this afternoon), I'd like to submit a patch to add OpenID login support to MediaWiki. Dan Libby has already contributed such a patch:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3060
Our patch (JanRain, Inc.) is a patch against CVS HEAD, extends Dan Libby's original modifications, and uses the PHP OpenID library that we built and maintain at
http://www.openidenabled.com/openid/libraries/php/
Here are some notes from the openid.txt file included in the patch:
OpenID support works in *addition* to normal wiki logins, including any external authentication plugin configured by the MediaWiki administrator. If a username looks like a URL, OpenID auth is tried; otherwise, the regular authentication rules apply.
If OpenID support cannot be verified (either because the library is missing or because the store directory can't be initialized -- see step (3) in Installation), MediaWiki will function normally even if $wgUseOpenID is set to true.
The account creation form cannot currently be used to create accounts with OpenID identity URLs. If you want to create an account with your OpenID, just log in. The account will be created automatically.
Any thoughts or concerns? I'm busy preparing some things and then I'll attach a .diff to the bug ticket above.
Lastly, provided that the patch is accepted at some point, I'll be happy to be active in supporting and maintaining OpenID support in MediaWiki.
Thanks!
-- Jonathan Daugherty JanRain, Inc. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Johannes Ernst NetMesh Inc.
# I assume that does OpenID, LID and YADIS given the development you # guys have been doing on those areas?
Nope. It's an OpenID-only patch.
# Is it just Relying Party support, or does it also enable registered # Wikipedia users to use their Wikipedia identity with other places?
The patch lets people use their OpenID identities to authenticate to MediaWiki; that's all.
On Jan 30, 2006, at 16:13, Jonathan Daugherty wrote:
# I assume that does OpenID, LID and YADIS given the development you # guys have been doing on those areas?
Nope. It's an OpenID-only patch.
# Is it just Relying Party support, or does it also enable registered # Wikipedia users to use their Wikipedia identity with other places?
The patch lets people use their OpenID identities to authenticate to MediaWiki; that's all.
In which case, I'd argue that we'd rather not deliver URL-based identity functionality piece-meal to the nice folks at Wikipedia who would probably like to avoid having to do more integration more often than necessary ...
I was told this morning that V0.9 of the YADIS spec is done as of yesterday and will be on-line shortly. The purpose of this spec -- which for all practical purposes could have been called 1.0RC1 -- is to give implementors like yourself the opportunity to provide final feedback, and will be renamed to 1.0 within the month or so unless something very unexpected happens.
For those of you on this list who don't know what this is all about -- YADIS is the discovery mechanism that "everybody" with URL-based identity technologies has agreed to, and as far as I know, most (all?) OpenID (and LID, and i-names, ...) implementors have agreed to "upgrade" their implementation to YADIS.
Of course, what does and doesn't make it into the Wikipedia code base when is entirely up to their team ... these are just my thoughts. And yes, I'd absolutely love to see broad URL-based identity support in Wikipedia...
-- Jonathan Daugherty JanRain, Inc. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Johannes Ernst NetMesh Inc.
# Any thoughts or concerns? I'm busy preparing some things and then # I'll attach a .diff to the bug ticket above.
I've uploaded the patch to the ticket at
http://bugzilla.wikimedia.org/show_bug.cgi?id=3060
# I've uploaded the patch to the ticket at # # http://bugzilla.wikimedia.org/show_bug.cgi?id=3060
I noticed that the earlier thread with Dan Libby pointed out that using dots to identify identity URLs will break over 12,000 WikiPedia accounts. I've added a newer version of the patch that fixes this and lets local authentication precede OpenID auth, unless a scheme is present in the username (in which case a local auth wouldn't be allowed, anyway). Please check it out and let me know what you think.
http://bugzilla.wikimedia.org/attachment.cgi?id=1337&action=view
Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jonathan Daugherty wrote:
I noticed that the earlier thread with Dan Libby pointed out that using dots to identify identity URLs will break over 12,000 WikiPedia accounts. I've added a newer version of the patch that fixes this and lets local authentication precede OpenID auth, unless a scheme is present in the username (in which case a local auth wouldn't be allowed, anyway).
Maybe they should be asked to give a local "alias" for this purpose? (ie, they login with their OpenID, but edits and other portions of the code use their alias.)
- -- Jamie - ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.
# Maybe they should be asked to give a local "alias" for this purpose?
The OpenID used to log in should be tied to a real wikidb account (and I assume that your "alias" is the wikidb.user record's "username" value). We explored implementing it this way, but the current patch requires no database changes and we figured that would be a nice migration selling point. But you're definitely right: using OpenID auth alongside normal auth in this way *does* effectively sidestep problems with trying to overlap username and OpenID namespace formatting rules.
On Mon, Jan 30, 2006 at 04:43:19PM -0800, Jonathan Daugherty wrote:
# Any thoughts or concerns? I'm busy preparing some things and then # I'll attach a .diff to the bug ticket above.
I've uploaded the patch to the ticket at
Hi, Jonathan. I'm at RecentChangesCamp right now, and I've just heard a good presentation about OpenID and Mediawiki.
I think this sounds like a really cool patch, and I'm going to check it out, but I think from my point of view, the most important application for Mediawiki users is single-signon for multiple wikis.
Mediawiki as a consumer of identities, and not a producer, isn't very useful for this.
I also want to point out that there are now thousands of small, large, and medium-sized wikis using Mediawiki, and that they'd probably all benefit from a federated signon solution.
Also, OpenID seems to me prima facie as a pretty good solution to single-signeon for Wikimedia. It seems like identity on Wikimedia sites is really tied to a particular site. People say, "I'm X from French Wikibooks" or "I'm Y from English Wiktionary"; I think Wikimedians could absolutely live with namespacing around a "base" project.
So I wonder: considering that single-signon is such a hugely requested feature for Mediawiki, and considering that OpenID is a lightweight solution that would allow SSO not only for Wikimedia sites but for Mediawiki sites across the Web, would we Mediawiki developers think about using this solution along with or instead of custom-built solutions that require access to the same backend database?
I'm going to try to work with this patch to get an optional piece of code that's suitable for checking in to CVS.
~ESP
Just FYI, I'm not even going to think about external identification wackiness like OpenID until we've finished the Wikimedia single-login system (my big project for February). So don't get discouraged if I don't comment. ;)
-- brion vibber (brion @ pobox.com)
On Tue, Jan 31, 2006 at 04:33:38PM -0800, Brion Vibber wrote:
Just FYI, I'm not even going to think about external identification wackiness like OpenID until we've finished the Wikimedia single-login system (my big project for February). So don't get discouraged if I don't comment. ;)
Brion,
Why not use OpenID FOR the Wikimedia single-login?
~ESP
evan@wikitravel.org wrote:
On Tue, Jan 31, 2006 at 04:33:38PM -0800, Brion Vibber wrote:
Just FYI, I'm not even going to think about external identification wackiness like OpenID until we've finished the Wikimedia single-login system (my big project for February). So don't get discouraged if I don't comment. ;)
Brion,
Why not use OpenID FOR the Wikimedia single-login?
It doesn't solve our specified requirement (single Wikimedia-wide namespace so a single username works on all 600+ Wikimedia wikis transparently, no muss no fuss).
-- brion vibber (brion @ pobox.com)
Brion Vibber <brion@...> writes:
evan@... wrote:
Why not use OpenID FOR the Wikimedia single-login?
It doesn't solve our specified requirement (single Wikimedia-wide namespace so a single username works on all 600+ Wikimedia wikis transparently, no muss no fuss).
Brion,
Hi. I'm an engineer at JanRain, Inc. We have been developing Internet identity systems for a while now. We specialize in OpenID.
I think that OpenID can meet your stated requirement. Is there a list somewhere of the other requirements for your authentication solution? I think that regardless of your requirements, there is an existing technology out there that can meet them. We are willing to do a lot of engineering to help wikimedia use an existing technology.
It seems to me that a wikimedia.org OpenID server would provide the namespace that you are looing for. It would also provide your users with an Internet-wide identifier at the same time.
Josh
Josh Hoyt wrote:
I think that OpenID can meet your stated requirement. Is there a list somewhere of the other requirements for your authentication solution?
The primary issue is the issue of unifying our username namespace so there are no longer any 'same username, different user' cases at our hundreds of wikis anymore.
This is outside the scope of something like OpenID, which explicitly uses separate namespaces (something we don't want).
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Josh Hoyt wrote:
I think that OpenID can meet your stated requirement. Is there a list somewhere of the other requirements for your authentication solution?
The primary issue is the issue of unifying our username namespace so there are no longer any 'same username, different user' cases at our hundreds of wikis anymore.
This is outside the scope of something like OpenID, which explicitly uses separate namespaces (something we don't want).
You could settle on one master namespace (wikipedia.org?), then gradually roll sites over to only accepting logins from that namespace, giving people the option along the way of merging their old separate identity histories into the new master login(s). I suspect OpenID could help with the cross-domain logins, even if a final single namespace is the only one accepted for logins.
I'd also guess that after starting to unify, there could be a backlash when people start losing their logins. Multiple namespaces might then seem more appealing.
Is there a page or past thread capturing prior discussion and decisions about the single-signon goal?
- Gordon
Gordon Mohr wrote:
Brion Vibber wrote:
Josh Hoyt wrote:
I think that OpenID can meet your stated requirement. Is there a list somewhere of the other requirements for your authentication solution?
The primary issue is the issue of unifying our username namespace so there are no longer any 'same username, different user' cases at our hundreds of wikis anymore.
This is outside the scope of something like OpenID, which explicitly uses separate namespaces (something we don't want).
You could settle on one master namespace (wikipedia.org?), then gradually roll sites over to only accepting logins from that namespace, giving people the option along the way of merging their old separate identity histories into the new master login(s). I suspect OpenID could help with the cross-domain logins, even if a final single namespace is the only one accepted for logins.
Given that you suggest "wikipedia.org", you do not appreciate that the uploading of pictures into Commons is one of the more pressing issues. There are MANY projects and wikipedia is only one.. :(
I'd also guess that after starting to unify, there could be a backlash when people start losing their logins. Multiple namespaces might then seem more appealing.
Is there a page or past thread capturing prior discussion and decisions about the single-signon goal?
- Gordon
The discussion on single-signon is old. It has been discussed to death. It has had special announced IRC chats dedicated to this subject and you can find the relevant stuff on Meta. A decision has been taken to implement this. Which is great given the problems that there is always someone new, who thinks that OpenID for instance had not been looked into.
When the unification starts, there will be people who hate it. However, you cannot make an omelette without breaking eggs.
Thanks, GerardM
Gerard Meijssen wrote:
Gordon Mohr wrote:
You could settle on one master namespace (wikipedia.org?), then gradually roll sites over to only accepting logins from that namespace, giving people the option along the way of merging their old separate identity histories into the new master login(s). I suspect OpenID could help with the cross-domain logins, even if a final single namespace is the only one accepted for logins.
Given that you suggest "wikipedia.org", you do not appreciate that the uploading of pictures into Commons is one of the more pressing issues. There are MANY projects and wikipedia is only one.. :(
Picking any one namespace as the starting space does not rule out any application on any Wikimedia project.
In any unification -- completely independent of technology used -- it would be natural to start with the one existing namespace. Maybe the largest/most-active, or perhaps the namespace which overlaps all others the most, or perhaps the namespace with the most unique names. You'd then work outward resolving conflicts with other namespaces one by one. And, despite starting with the largest (or most-overlapping or most-unique), that namespace wouldn't necessarily win most conflicts. (It might lose most, because its size means a longer tail of seldom-used accounts.)
I'm guessing the Wikipedia projects are still largest (and also have the most overlap with others and the most unique names), but would be interested in pointers to any numbers which suggest otherwise.
(If existing project names are loaded with politically undesirable semantics, perhaps the best course would be to pick a relatively cryptic, semantically-unloaded 'name' for the unified login -- "WMLX" or some such, which is vaguely but not really an abbrieviation. Then start rolling other legacy namespaces into it. )
My point is the same: you can pick a single namespace, and wind up with a single namespace at the end of the transition, completely independent of the technology used.
Some people seem to be assuming that OpenID/YADIS *necessarily* means allowing signins from multiple and/or foreign namespaces. By my understanding, that's not the case.
I can't tell which of the three options listed at http://meta.wikimedia.org/wiki/Single_login_poll had the most developer support, but SUL-2 and SUL-3 both seem to suggest a transition phase where global and local coexist for a while. That would seem a natural application of the OpenID/YADIS approach, with a single global namespace exporting itself to any number of projects which accept global logins, but still have legacy local logins as well.
I'd also guess that after starting to unify, there could be a backlash when people start losing their logins. Multiple namespaces might then seem more appealing.
Is there a page or past thread capturing prior discussion and decisions about the single-signon goal?
- Gordon
The discussion on single-signon is old. It has been discussed to death. It has had special announced IRC chats dedicated to this subject and you can find the relevant stuff on Meta. A decision has been taken to implement this. Which is great given the problems that there is always someone new, who thinks that OpenID for instance had not been looked into.
I thank Rob Lanphier for providing a link to the Single_login_specifications page at Meta.
- Gordon
wikitech-l@lists.wikimedia.org