Topic on Extension talk:OpenID Connect

Problems using newer versions of jumbojett/openid-connect-php

11
Summary by Cindy.cicalese

Updated to new release of OpenID Connect PHP library

HerrTaschenbier (talkcontribs)

I was using OpenID Connect with mediawiki 1.28.2. For some reason I was installing jumbojett/openid-connect-php:0.1.0 manually during installation. Everything was working fine.

With the update to 1.29.1 I figured out that this line was unnessicary because the dependencies are already listed in the composer.json coming with this extension. So I removed it from my Dockerfile (I'm using Docker).

After installation, login didn't work. I switched back to my 1.28.2 build (worked before), removed the same line from my Dockerfile. Similar issue.

I came to the conclusion that the version of jumbojett/openid-connect-php was causing this issue.

I temporarily solved it by editing the composer.json of the "OpenID Connect" extension, requiring version 0.1.0 instead of *.

Does anybody have the same issue?

----------

concrete information:

oAuth server: Gluu Identity Appliance 2.4.4.sp2 (shoudn't matter I guess)

I have this on for debugging

$wgDebugToolbar = true;

$wgDevelopmentWarnings = true;

$wgShowExceptionDetails = true;

$wgShowDBErrorBacktrace = true;

$wgShowSQLErrors = true;

--------------------------------------------------

mw vers: 1.28.2

OpenID vers: 3.0 (648beef)

Pluggable Auth vers: 2.0 (cdb0435)

jumbojett/openid-connect-php:0.1.0:

- works fine

jumbojett/openid-connect-php:0.3.0:

- doesn't work

- get oAuth loginpage if cookie isn't set

- get redirected to "http://wiki.local/index.php/Spezial:PluggableAuthLogin?code=..." (url includes user_id etc.) if oAuth cookie is set

- get this error message at the top of the page 2x:

"Notice: Did not find alias for special page 'PluggableAuthLogin'. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php at line 692] in /var/www/html/wiki/includes/debug/MWDebug.php on line 311"

--------------------------------------------------

mw vers: 1.29.1

OpenID vers: 4.0 (648beef)

Pluggable Auth vers: 4.0 (cdb0435)

jumbojett/openid-connect-php:0.1.0:

- seems to work

jumbojett/openid-connect-php:0.3.0:

- doesn't work

- get oAuth loginpage if cookie isn't set

- get redirected to "http://wiki.local/index.php/Spezial:PluggableAuthLogin?code=..." (url includes user_id etc.) if oAuth cookie is set

- no error visible

- from debug log:

OpenIDConnectClientException: Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client. in /var/www/html/wiki/vendor/jumbojett/openid-connect-php/OpenIDConnectClient.php:228

Stack trace:

#0 /var/www/html/wiki/extensions/OpenIDConnect/OpenIDConnect.class.php(151): OpenIDConnectClient->authenticate()

#1 /var/www/html/wiki/extensions/PluggableAuth/PluggableAuthLogin.php(45): OpenIDConnect->authenticate(NULL, NULL, NULL, NULL, NULL)

#2 /var/www/html/wiki/includes/specialpage/SpecialPage.php(522): PluggableAuthLogin->execute(NULL)

#3 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(578): SpecialPage->run(NULL)

#4 /var/www/html/wiki/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))

#5 /var/www/html/wiki/includes/MediaWiki.php(862): MediaWiki->performRequest()

#6 /var/www/html/wiki/includes/MediaWiki.php(523): MediaWiki->main()

#7 /var/www/html/wiki/index.php(43): MediaWiki->run()

#8 {main}

Cindy.cicalese (talkcontribs)

There were some necessary fixes made to the library that are available on the dev branch, so earlier this month I patched the extension to use that version of the library. If you checkout the head of the master branch of the extension (currently 2983431ea864), you should see that composer.json specifies dev-master for the library. I have tested this under MediaWiki 1.29.

HerrTaschenbier (talkcontribs)

I would feel a bit uncomfortable using the dev branch. The docker container would always run the latest development version when rebuilding.

There is an issue on GitHub requesting a new release for composer. I guess I'll wait until the new version is released before upgrading.

Thank you for your answer.

Cindy.cicalese (talkcontribs)

Yes, I agree completely. I struggled with the decision to update to the dev branch, but since the last release was no longer working, I made the change. I will switch back once there is a working composer release. Feel free to ping me if I miss a release announcement.

HerrTaschenbier (talkcontribs)

Hi, I decided to update to Mediawiki 1.30.0 since I don't believe that there will be a new release for jumbojett/openid-connect-php any time soon.

Now I'm using Mediawiki 1.30 + (updated) Extensions.

OpenID Connect 4.0 (2983431)

PluggableAuth    5.2 (2528a75)

Everything else is unchanged. When I try to login now, I get this error message:

Error from line 130 of /var/www/html/wiki/extensions/OpenIDConnect/OpenIDConnect.class.php: Class 'OpenIDConnectClient' not found

Adding "use \Jumbojett\OpenIDConnectClient;" to the beginning of OpenIDConnect.class.php seems to be working. However I was rather confused because:

1. I don't think you would miss such an obvious bug

and 2. I compared this version of the extension with the one I'm currently using and there is not much of a difference.

There was no "use \Jumbojett\OpenIDConnectClient;" in the old version either and yet it works. I'm too inexperienced find the cause for this problem. I figured that "require "{$IP}/vendor/autoload.php";" is (?) important to load the library. I'm already using this in my config (before I load PluggableAuth and OpenIDConnect). Am I missing something obvious?

Cindy.cicalese (talkcontribs)

The namespace was added to the jumbojett library after version 4.0 of the extension was released, so the older versions of the extension did not need that line of code. I added the line to include the namespace on January 20, so if you get "master" from git you should get it. But, I see that I forgot to bump the version number to 4.1, tag the release, and update the documentation page. Thank you for bringing this to my attention! I will add that to my to do list.

However, you should not need to require the autoload file. That is handled automatically by the composer autoloader.

Cindy.cicalese (talkcontribs)

Release version 4.1 is now tagged.

HerrTaschenbier (talkcontribs)

So I guess my problem came from the extension requiring master-dev (which you needed to do because there was no new tag for the jumbojett library). When the library updated, the extension broke, because it didn't use the newly added namespace, right?

When I was searching for the root of the problem, I took a look at the composer.json. Currently it looks like this:

<--snip-->

"repositories": [

       {

           "url": "https://github.com/jumbojett/OpenID-Connect-PHP.git",

           "type": "git"

       }

   ],

   "require": {

       "jumbojett/openid-connect-php": "master-dev"

   },

<--snip-->

I did a quick Google search and found this. If I understand this correctly, you can clone the library directly from git via composer and require a specific version. Not just a branch but also a tag or a specific commit (via hash).

Wouldn't your extension be more reliable, if you tested your extension with a specific version of the library and then require this specific commit instead of master-dev? At least until a new version of the jumbojett library is released.

Anyway thank you very much for your fast reply and the new version :)

Cindy.cicalese (talkcontribs)

Yes, I wrestled with whether or not to do that. Since we're using the dev branch, I didn't want to preclude users from getting bug fixes with more recent versions, but I also would like to prevent them from getting bugs from more recent versions. You are correct that pinning to a known good version would probably be best. That version can always be reevaluated and bumped with future releases of the extension. If there is a particular recent git tag that is working well for you, please feel free to suggest it or, better, submit a patch in gerrit to the composer.json file changing the require statement. Thanks!

HerrTaschenbier (talkcontribs)
Cindy.cicalese (talkcontribs)

Excellent! Thanks for letting me know. I will switch back to using the released version of the code as soon as I get a chance to test it and make the change.