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 stringhttp://psmay.com/
is compared against the allow/deny lists, delegation and authentication takes place, and then I am confirmed as having signed in ashttp://psmay.com/
. My user's account has been associated with this URL. - When I sign in with
psmay.com
, that is converted tohttp://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 stringhttp://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 stringpsmay.com
is compared against allow/deny, then converted tohttp://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?