-
Bug
-
Resolution: Fixed
-
Minor
-
3.3.1, 3.4
-
MOODLE_33_STABLE, MOODLE_34_STABLE
-
MOODLE_33_STABLE, MOODLE_34_STABLE
-
MDL-59512-master -
Test setup
- Ensure version.php and upgrade.php have the correct version id to allow core DB upgrade.
- Upgrade the database.
- Test the following two scenarios.
Test a non-conformant client to verify that no regression happened
- In Google, set up your Moodle as a Google OAuth client following https://docs.moodle.org/33/en/OAuth_2_Google_service#OAuth_2_Google_service_setup ; jot down Client ID and Secret somewhere, you'll need it later.
- In Moodle, go to Dashboard > Site administration > Server > OAuth 2 services.
- Click "Create new Google service".
- Paste Client ID and Secret from the first step.
- Make sure that "Authenticate token requests via HTTP headers" is disabled.
- Leave the remaining options unchanged and click "Save changes".
- In the issuers table, click "Connect to a system account" in the line of the issuer that you just created.
- Click through the following screens, thus connecting your own Google account (or one for testing purposes) as a system account. Moodle
should not throw any exceptions. (In contrast, any Google errors hint at a misconfiguration). - Confirm that the functionality works as before by verifying that your Google account name shows up next to the "Connect to a system account".
Test a conformant client to verify that the patch adds support for Basic Auth
- Quickly obtain a Nextcloud demo instance from https://demo.nextcloud.com, "Instant trial" (no manual installation required).
- Configure Nextcloud and Moodle according to steps 1 and 3 of https://github.com/learnweb/moodle-repository_owncloud/blob/master/README.md#installation .
- In the issuers table, click "Edit" in the line of the issuer that you just created. Enable "Authenticate token requests via HTTP headers" and click "Save changes".
- In the issuers table, click "Configure endpoints" in the line of the issuer that you just edited.
- Create a new endpoint userinfo_endpoint with the URL <Demo Nextcloud Base URL>/ocs/v2.php/cloud/user?format=json, save it and return to the list of issuers. (ownCloud: <ownCloud Base URL>/ocsapp/cloud/user?format=json - but does not seem to work with OAuth yet
) - In the issuers table, click "Connect to a system account" in the line of the issuer that you just edited.
- Click through the following screens, thus connecting the demo Nextcloud account as a system account. Due to a problem in Nextcloud (unnecessary CSRF checks even on OAuth authenticated requests , known to Nextcloud since July) Moodle will raise an invalid_persistent_exception. Sorry, this is expected (but actually a good sign, as Basic auth has worked then!). Note that this would work with ownCloud, but you cannot get a testing instance as easily, so you would have to set up ownCloud on your machine. That's why I opted for Nextcloud here nevertheless.
Test setup Ensure version.php and upgrade.php have the correct version id to allow core DB upgrade. Upgrade the database. Test the following two scenarios. Test a non-conformant client to verify that no regression happened In Google, set up your Moodle as a Google OAuth client following https://docs.moodle.org/33/en/OAuth_2_Google_service#OAuth_2_Google_service_setup ; jot down Client ID and Secret somewhere, you'll need it later. In Moodle, go to Dashboard > Site administration > Server > OAuth 2 services. Click "Create new Google service". Paste Client ID and Secret from the first step. Make sure that "Authenticate token requests via HTTP headers" is disabled. Leave the remaining options unchanged and click "Save changes". In the issuers table, click "Connect to a system account" in the line of the issuer that you just created. Click through the following screens, thus connecting your own Google account (or one for testing purposes) as a system account. Moodle should not throw any exceptions. (In contrast, any Google errors hint at a misconfiguration). Confirm that the functionality works as before by verifying that your Google account name shows up next to the "Connect to a system account". Test a conformant client to verify that the patch adds support for Basic Auth Quickly obtain a Nextcloud demo instance from https://demo.nextcloud.com , "Instant trial" (no manual installation required). Configure Nextcloud and Moodle according to steps 1 and 3 of https://github.com/learnweb/moodle-repository_owncloud/blob/master/README.md#installation . In the issuers table, click "Edit" in the line of the issuer that you just created. Enable "Authenticate token requests via HTTP headers" and click "Save changes". In the issuers table, click "Configure endpoints" in the line of the issuer that you just edited. Create a new endpoint userinfo_endpoint with the URL <Demo Nextcloud Base URL>/ocs/v2.php/cloud/user?format=json , save it and return to the list of issuers. (ownCloud: <ownCloud Base URL>/ocsapp/cloud/user?format=json - but does not seem to work with OAuth yet ) In the issuers table, click "Connect to a system account" in the line of the issuer that you just edited. Click through the following screens, thus connecting the demo Nextcloud account as a system account. Due to a problem in Nextcloud (unnecessary CSRF checks even on OAuth authenticated requests , known to Nextcloud since July ) Moodle will raise an invalid_persistent_exception . Sorry, this is expected (but actually a good sign, as Basic auth has worked then!). Note that this would work with ownCloud, but you cannot get a testing instance as easily, so you would have to set up ownCloud on your machine. That's why I opted for Nextcloud here nevertheless.
Currently, when a refresh token is upgraded to an access token, client ID and client secret are transmitted via the request payload: https://github.com/moodle/moodle/blob/350700bf8b509f5269b0fefd34fec0d3d5393c99/lib/classes/oauth2/client.php#L180. However, this is discouraged by the OAuth 2 standard (in context):
Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes).
Therefore, transmitting client ID and secret via Basic Auth (instead of the payload) should be supported, at least with a per-service choice. I would even suggest to fully move to the Basic Auth mechanism, because
The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.
... however, I don't know how well Google and Microsoft adhere to the specs – this should be investigated first.
Either way: ownCloud currently only supports authentication via the Basic method; authentication via the payload fails as unauthorised.
