Last modified: 2013-02-24 07:15:30 UTC
I go to http://www.techpresentations.org/Special:OpenIDLogin and use http://yahoo.com/ as my OpenID URL (click on Yahoo! button in provider selector), Yahoo! brings up a dialog to request which identity to use and I pick "https://me.yahoo.com/sergeychernyshev (Last used)" from a drop-down. This brings me back to my MediaWiki instance and if it is a first time, it asks me to create an account or pick existing one (I pick my existing account). Then if I go to http://www.techpresentations.org/Special:Preferences I can see that I have new identity in the list of OpenID URLs: https://me.yahoo.com/sergeychernyshev Now, when I go to http://www.techpresentations.org/Special:OpenIDConvert (there is a button called "Add a new OpenID") and use http://yahoo.com/ (clicking Yahoo! button again), it brings me exactly the same interface on Yahoo!'s end with exactly the same value in the identity drop-down: "https://me.yahoo.com/sergeychernyshev (Last used)", but when I submit the form, it doesn't recognize me as existing identity and offers to link to MediaWiki account again instead of just telling me that I already have this identity assigned. When I go to http://www.techpresentations.org/Special:Preferences again to check the list of OpenID URLs assigned to my account, I see that in addition to original https://me.yahoo.com/sergeychernyshev I now also have https://me.yahoo.com/sergeychernyshev#5d2f8 as an identity. Both of these URLs are consistent, e.g. when I go through Special:OpenIDLogin, I get https://me.yahoo.com/sergeychernyshev and when I get through Special:OpenIDConvert, I get https://me.yahoo.com/sergeychernyshev#5d2f8 regardless if I had this URL already or not (you can test by deleting OpenID URLs from your preferences and checking if it matches). This is an issue and it's not clear if it is on MediaWiki's side or on Yahoo's side. P.S. I always get consistent results if I use MyOpenID through delegation from my http://www.sergeychernyshev.com or if I use Google or my account on LiveJournal so it might be related to some features of Yahoo! implementation (either wrong or newer versions or maybe related to some privacy issues based on different contexts - I have no idea and it needs more research).
Mass maintainer change.
Sergey, as far as I understand your report, and from my experience with for example Google OpenID, it is clear, that some providers assign different OpenID urls for the same user, depending on the consumer domain or url. references: + http://stackoverflow.com/questions/2577269/googles-openid-identifier-is-different-depending-on-the-consumer-domain-name Extension:OpenID as Provider uses a fixed OpenID in the form http://server/mediawiki/User:Username regardless what the consumer domain or url is. The generic OpenID format (the mediawiki OpenID provider shows a login form then for identity selection) is http://server/mediawiki/Special:OpenIDServer/id [I intentionally designed this similar to the corresponding Url of Google). I close this bug now, because I think, we cannot change the behaviour of a few Thirs party OpenID providers who use different OpenID Urls.
Well, if 3rd party providers return different URLs for same consumer domain, that is a general issue - if they create different URLs for different pages on same domain (e.g. login screen vs. convert screen), then it should be change on MW side to make sure 3rd party providers see same wiki as one consumer. P.S. I actually didn't test this recently and can't really make sure if this is still the case. So notes above are just thoughts on the issue, not a confirmation that it is still a problem.
Hi, thanks for your explanation . Now I fully understand, what you mean. I checked it again. It is true, that Yahoo returns an OpenID such as https://me.yahoo.com/myyahoousername#50fc0 but you can login (on E:OpenID-powered MediaWikis) with https://me.yahoo.com/myyahoousername . I just successfully checked this; I do not know, why Yahoo used the #part - perhaps to avoid caching. Url parts after the "#" do not matter, and are not transmitted, as far as I know (for example, some client-side en/decryption methods rely on this.) Thanks again, I think it's clever to have this information here, but staying as "resolved invalid".
