Page MenuHomePhabricator

Need help configuring an already-registered Wikimedia OAuth consumer
Closed, ResolvedPublic

Description

The Community Development team is setting up a learning platform on a hosted Moodle instance, outside WMF infrastructure. It is essential that learners be able to log in with their Wikimedia identities, so we want to use Moodle's OAuth consumer capabilities to allow Wikimedia logins.

I have already applied to register our Moodle as a Wikimedia OAuth consumer, and it has already been approved.[1] So we have the client ID and client secret.

We now need help figuring out the precise strings to feed into the "endpoints" fields in the OAuth configuration on the Moodle side. I understand WMF Engineering isn't necessarily familiar with Moodle, but an engineer familiar with our OAuth implementation would be well-equipped to figure out how to configure it. The Moodle documentation[2] on the OAuth feature, focusing on OAuthing versus Google etc., was not sufficient for me to figure out custom providers without delving into the codebase.

If you could identify an engineer with familiarity with Wikimedia OAuth to devote (in my estimate) between 1 and 2 hours to helping us accomplish this integration -- a one-time effort -- we would be very grateful.

I will be the contact person working with that engineer, providing the login credentials and navigation within the Moodle configuration, to minimize the time the engineer has to spend on anything but the core issue.

Thanks!

A.

[1] https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/7800c725db56ae33be9b597208b1e87a
[2] https://docs.moodle.org/310/en/OAuth_2_services

Event Timeline

I note https://www.mediawiki.org/wiki/OAuth/For_Developers and more specifically https://www.mediawiki.org/wiki/OAuth/For_Developers#OAuth_2 should (in theory), be enough to get going.

However, taking this part

Ask the user to authorize the application by sending them to oauth2/authorize under the wiki's REST endpoint (usually rest.php)

It's not going to be obvious what rest.php is, nor where to find it, unless you're probably pretty familiar with MW (or otherwise technical/familiar with these sorts of API endpoints)

Helpfully https://www.mediawiki.org/wiki/Special:Version does actually disclose where this is - https://www.mediawiki.org/w/rest.php. But it wouldn't be unreasonable to have an example (though not completely working as it's not really supposed to be an interactive workflow) url, showing where the endpoint is on the current wiki (ie mediaiwki.org)

While I want to try and avoid assigning people work, it seems this might be a useful "use case" for @apaskulin with relation to the API Portal Documentation efforts - if one person can't necessarily find the information they need, it's possible other people may struggle too. See also tasks like T253568: Make the terminology of OAuth UI and documentation easy to understand and T253447: OAuth2 docs seem confused/incomplete

Thank you, @Reedy. I did indeed peruse the [[OAuth/For_Developers]] page, which is how I got as far as registering my OAuth client and receiving my credentials. However, I am probably still missing something.

I attach the OAuth settings screen from Moodle (with the credentials redacted, of course, but rest assured I have put the Client ID and Client secret in correctly), in case what's missing is obvious to anyone.


Since taking the screenshot, I have tried pasting https://www.mediawiki.org/w/rest.php into the service URL field, but I'm getting a 403 error. Some Moodle forum posts suggest this means no authorization_endpoint was found.

It is no doubt a problem on the Moodle configuration side, but yes, the documentation could be clearer: for instance, the Moodle screen asks me about the "scopes" to include in the request, and the documentation says nothing about scopes at all. Are what Moodle calls "scopes" what Mediawiki calls "grant types"? Does our "service base URL" support "endpoint discovery"?

This is why my team is requesting the allocation of an hour or two of time of an engineer familiar with the Mediawiki side of OAuth, which no doubt would enable the speedy resolution of this configuration issue on the Moodle side.

Progress(?) -- I have defined endpoints by some wild guessing and peeking at some client code, as follows:


Which now gets me to an actual OAuth error, as follows:

This is where I repeat my request for probably-no-more-than-an-hour of the time of someone familiar with OAuth in Mediawiki, to get this sorted.

I'm not an expert, but I can try to help until someone else can jump in. For the endpoint mappings, you'll want:

Are what Moodle calls "scopes" what Mediawiki calls "grant types"? Does our "service base URL" support "endpoint discovery"?

I'm not 100% sure about these, but my guess would be that we don't support endpoint discovery and that it seems like Moodle scopes are specific to what you can do within Moodle as opposed to connecting to something on the MediaWiki side.

Progress(?) -- I have defined endpoints by some wild guessing and peeking at some client code, as follows:

Those look like the endpoints you would be using if you were using OAuth 1

Thank you! Using the correct manual endpoints seems to have taken me a step further. I now get a Moodle error "The requested scope is invalid, unknown, or malformed", presumably referring to one or more of the three "scopes" in the config field shown above, viz. "openid profile email".

Can anyone provide clarity on which of these "scopes" may not be provided by Mediawiki, and whether there are any *other* "scopes" I may need to list here instead?

Assuming that Moodle is passing these scopes to the /authorize endpoint, I believe MediaWiki would be expecting either no scopes (since the scope parameter is optional) or the scopes that match your client, which looking at your link in the task description should be just mwoauth-authonlyprivate. Hope this helps!

Thank you. The scope parameter is not optional on the Moodle side, so I'm forced to put some value in there. Trying both "mwoauth-authonlyprivate" and "openid mwoauth-authonlyprivate", I did not even get as far as Meta's error message (instead getting an apparently spurious 403 Forbidden on the Moodle server itself, like the one described in https://phabricator.wikimedia.org/T271078#6723663

So attention is still needed. This is a blocker for our team's main quarterly goal of launching this platform so that it's useful for Wikimedia users.

Are there any "Additional parameters included in a login request" I should input in the eponymous optional field in Moodle's settings?

Just as a wild moonshot - try authonlyprivate?

Is there any more details you can find about the 403? how does getting 403 look like?

No luck with authonlyprivate either.

The 403 is a real Apache 403 page:

Clearly poor and misleading error reporting on Moodle's side.

To make sure I understand, when you entered these scopes: "openid profile email", you received the error message "The requested scope is invalid, unknown, or malformed".

Then when you changed the scopes to either "authonlyprivate" or "mwoauth-authonlyprivate", you no longer received that message, and instead received a 403?

What error do you get if you put gibberish into the scope field? ("foobar", "AsafIsFrustrated", or whatever random string you prefer)

Confusing indeed! Turns out that the custom endpoints definitions were silently deleted (reset to empty) when I made changes to the scopes field. I have now re-populated the custom endpoints, and we're back to the "The requested scope is invalid, unknown, or malformed" error.

I have now re-populated the custom endpoints, and we're back to the "The requested scope is invalid, unknown, or malformed" error.

To clarify, you're using mwoauth-authonlyprivate and it's malformed? One possibility is that moodle doesn't allow for dashes in the scope name, so it would be interesting to try something like abcd and see if you get the same error.

Asaf claimed this task.

Exciting update: Turns out that I never properly tested the "mwoauth-authonlyprivate" option, because of that silent clearing of the custom endpoints config. I have now done that, and seem to have gotten a proper OAuth handshake completed!

Thank you, everyone, it looks like I'm good to go from here on, so I'll resolve this ticket. (The documentation gap is still an issue to be addressed, of course.)