By prematurely loading custom profile data in the constructor, under
specific circumstances it would happen before the page was fully
initialised which meant that any attempt at applying filters when
formatting profile field data would result in thrown exception.
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
Update oauth2 to allow mapping of provider attributes against
user profile fields. Fields can also be locked to prevent
user changes.
Co-Authored-By: Michael Milette <michael.milette@tngconsulting.ca>
* Updating of user profile data from OAuth2 issuer should only be
performed for fields that can be synced externally (fields defined in
\auth_plugin_base::$userfields)
* Only update user profile data for users which use OAuth2 as their
default authentication mechanism.
The login domains were checking the email of the moodle account, not the returned
email from oauth. Also after a failure, it was not killing the oauth session, which
prevents you trying again with a different account.
This was broken by the refactoring to always link logins. Some of the static
variables could also be removed but I'll do that in a later issue to keep this patch small.
New accounts and linking a login to an existing account MUST go through email verification.
We cannot trust the emails we get from oauth providers have been confirmed.
Part of MDL-58220
Paul Holden