Topic on Extension talk:OpenID

TL;DR: Since the last time I upgraded, the extension has changed from using, checking, and storing the given URL to doing so with the delegate URL when delegation is in use. This doesn't work well for our system.

Just upgraded to 4.03 from…0.9.0 (!) and have found a change that I need to either disable or revert to get our wiki back up and running.

There is a site that I run, one with a short URL (http://psmay.com/), and I'm using OpenID's delegation facility to delegate to Launchpad as the provider that authenticates for that page (i.e. <link rel="..." href="https://login.launchpad.net/..." /> elements are provided for openid.server, openid.delegate, openid2.provider, and openid2.local_id).

Apparent previous (and as far as I am concerned, correct) behavior:

• When I sign in with http://psmay.com/, the string http://psmay.com/ is compared against the allow/deny lists, delegation and authentication takes place, and then I am confirmed as having signed in as http://psmay.com/. My user's account has been associated with this URL.
• When I sign in with psmay.com, that is converted to http://psmay.com/, and the process continues as above. (I am not sure whether allow/deny is applied before or after the conversion.)

Current behavior:

• When I sign in with http://psmay.com/, the string http://psmay.com/ is compared against the allow/deny lists, delegation and authentication takes place, the ultimate delegate URL is compared against allow/deny, and I am confirmed as having signed in as the delegate URL. That URL not being in the database, the extension offers to associate me with another user.
• When I sign in with psmay.com, the string psmay.com is compared against allow/deny, then converted to http://psmay.com/, and the process continues as above.

While I realize that the change might actually have been intentional, there are issues with the new behavior:

• Both the user URL (http://psmay.com/) and the delegate provider URL (https://login.launchpad.net/...) must be accounted for in the allow/deny patterns. For our purposes, only the user URL should be important.
• The URL representing the user has been changed from the user URL to the delegate URL.
  • Any user account already associated with a URL that delegates is now broken.
  • If I fix up the database so an account is now connected to the delegate URL, the user can't later decide to change to another delegate URL without losing access.

Any way to fix or work around this? Am I the first to ask?

I need to understand your report, allow me some time. The present moment (Heartbleed fixes and other things) is not so well suited.

Just one remark: the old OpenID extension versions did never correctly handle the delegation, only the new versions do. So we both should concentrate to find, why the new version is (perhaps) not working within your environment. I suggest you remove(open, drop) the allow/deny restrictions, and check the exact url. In almost all cases I do remember, there was a difference between the Url you see and the Url which the remote server sees with MediaWiki (I mean the difference between server/wiki/Special:Pagename and server/w/index.php/Special:Pagename for example.).

And I also suggest - if you can - to run the latest core Mediawiki and latest OpenID extension on latest PHP 5.5.11.

You are also invited to file a bugzilla https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=OpenID for this (copy the texts from here, and leave a link the bugzilla). Bugzilla is better trackable, and allows attachments, links to gerrit etc.