Ashar Voultoiz wrote:

Dan Libby wrote:

...

Hi all, I've created a patch for OpenID login to MediaWiki. ( 1.4.10 )

Details here: http://wiki.www.videntity.org/wiki/MediaWiki_OpenID_Patch

Can you port it on 1.5.0 and eventually try to get a patch for HEAD ? It would be interesting to get openid support for 1.6 (or later).

Yes, I can do that.

It should be noted though that this patch may not the best way to do things long term.

A couple things:

1) this patch piggy-backs on top of SpecialUserlogin. So if a username contains "://" or '." then the OpenID code kicks in. This does not provide any sort of possibility for other login types, eg LID. Also it would break any pre-existing logins with those strings in them.

2) MediaWiki insists on upper-casing all titles, including usernames. I worked around that for actually storing the username, but it still happens for display,which looks kinda nasty for eg: "Http://danda.videntity.org/". I'm not sure how to get around that as the title normalization stuff is a bit, umm, inscrutable.

I'm wondering if someone on the core team could perform a code review of the patch and either:

a) give it a tentative blessing, with some pointers for ways to deal with the above issues.

b) reject it as "the wrong way" to do things.

If it has a tentative blessing, then I'm more inclined to port it to 1.5.0 and do whatever is necessary to make it "right".

I figure that even if it is the wrong way, at least it works now for my wiki and anyone else who want to use it, and may prove useful as sample code for someone to do it "the right way", whatever that might be.

regards,

Dan Libby

Ævar Arnfjörð Bjarmason wrote:

Regarding your comments in the patch regarding on the usernames we restrict: We require usernames to be upper case for future compatability with single login.

Anyway, have you considered making this an extension? (see docs/hooks.txt), I looked it over and found that it would be trivial to do all this through $wgHooks by sprinkling a few wfRunHooks();

I'd be happy to make it an extension if someone can define and add the necessary hooks.

I'm curious if anyone has looked at how I added processLogin() to AuthPlugin() in order handle multi-page authorization sequences. I imagine your LID patch must do something similar, eh Johannes?

There is still the matter of how to determine that the current login should be processed via OpenID ( or LID, or... ) rather than by the normal MediaWiki login handler. Checking for '.' in the login was a temporary hack. I suppose that each login-type could have its own login page, but that still leaves the question of how/where the user chooses the login type.

On Oct 6, 2005, at 19:50, Brion Vibber wrote:

Using URLs for usernames is going to be inherently broken on the wiki, as accounts are closely tied to their user pages on the wiki.

We've been doing some work integrating LID (the "other" URL-based digital identity system) with WikiPedia, and while ugly, even user talk pages work surprisingly well with very few changes, for the LID URLs we tried so far. I guess that will be the same for Dan and OpenID. The MediaWiki code is more robust than we thought ;-)

<snip />

There are basically two ways you can go I think:

1. OpenID identifiers are a special class of users and handled

distinctly, like anonymous IP addresses are.

That's probably the most appealing route. This would apply to all REST-ful identifiers for authors, and potentially for non-URL-based "outside" identifiers as well, like URNs or XRIs (see the Identity Commons project, which is another personal digital identity effort).

Some mechanism for displaying properly formatted names and for picking a not-too-illegible title for the user page / talk page would need to be added to the core code.

The issue here is privacy and what follows from there. Within LID, for example, we have extensive facilities for voluntary "profile data exchange" (see the LID MediaWiki ;-) at http://lid.netmesh.org/ wiki ), so it's very straightforward to determine what VCard calls the "Formatted Name" for a user, but experience shows that people don't necessarily want others to see their real name in public places such as Wikipedia.

Also, there is a namespace issue. The reason DNS is hierarchical is that there are simply too many things that need to be named to be in one, flat namespace. As Wikipedia grows to, say, include every graduate student ever (kindergartener?), how realistic is it to stay with a single-level name space? And the whole point of OpenID, LID, and all the internet-scale identity efforts is to get away from local pseudonyms that need to be invented because somebody else took john.doe already at that site.

I'm afraid that I don't have a full-fledged answer here (not sure anybody does), except for the maybe-not-so-trivial one: what if users with REST-ful outside identifiers don't get a talk page?!? Chances are that their REST-ful identifier actually refers to their blog, or some place where people can leave comments ... Other than User:xxx, where else would something break? It's easy to format, say, SpecialListusers differently if it is a URL ...

2. OpenID identifiers can be used to authenticate a named account in

place of a password, but you have to pick a valid username name and create an account.

Account federation with local pseudonyms... let's not do that, it's a kludge and not worth the effort ...

So much for now ...

Johannes Ernst

http://netmesh.info/jernst

Johannes Ernst

http://netmesh.info/jernst

Brion Vibber wrote:

Dan Libby wrote:

...

1. this patch piggy-backs on top of SpecialUserlogin. So if a username

contains "://" or '." then the OpenID code kicks in. This does not provide any sort of possibility for other login types, eg LID. Also it would break any pre-existing logins with those strings in them.

The . check would break... 12579 registered usernames on en.wikipedia.org. :)

Ouch. So clearly a better solution is needed for the user to specify which type of Login system to use.

I've seen a couple sites that have a dropdown selector on the login page for the user to pick the login type. That seems pretty clean to me.

...

2. MediaWiki insists on upper-casing all titles, including usernames. I

worked around that for actually storing the username, but it still happens for display,which looks kinda nasty for eg: "Http://danda.videntity.org/". I'm not sure how to get around that as the title normalization stuff is a bit, umm, inscrutable.

Using URLs for usernames is going to be inherently broken on the wiki, as accounts are closely tied to their user pages on the wiki. To be non-broken, the usernames need to be real, valid page titles. There are many valid URLs which are not valid titles, and trying to use them like that is I think going to be a tangle of ugliness, special cases, and identifiers which won't be able to login despite having a valid OpenID system.

I worked around this issue by forcing URLs to always use the "?title=" format if the title contains "/". Otherwise there were problems with Apache (php?) munging "//" in the PATH_INFO variable into "/".

It was a pretty simple check in Title::getLocalURL(), not much of a tangle.

afaik, user talk pages are working fine for OpenID logins.

Also, that seems like an issue that would affect any titles with "//", but probably it is not a common case so possibly no one has run into it yet.

There are basically two ways you can go I think:

1. OpenID identifiers are a special class of users and handled

distinctly, like anonymous IP addresses are.

Interesting. I wasn't aware of the distinction.

Some mechanism for displaying properly formatted names and for picking a not-too-illegible title for the user page / talk page would need to be added to the core code.

Every place that takes a username in input, displays a username in output, or tries to make a user page link would need to change. (That's not that bad an idea, though; consolidation of duplicated code would be good and other external authentication systems could use this same ability.)

-or-

2. OpenID identifiers can be used to authenticate a named account in

place of a password, but you have to pick a valid username name and create an account. (This could be as simple as confirming an automatic transformation of the OpenID identifier or choosing to change it during your first login.)

Easy, but of course not as 'cool'. :)

I'm not sure it is so easy actually.

This approach would seem to defeat much of the benefit of OpenID if it is not automatic. Who wants to login with their universal ID only to have to choose a local ID?

The difficulty with an automatic approach is guaranteeing a transform that looks nice and yet is still unique. For plain http:// urls, you can get rid of the "http://" portion because it is assumed, but you can't do that if the url starts with "https://".