When retrieving userinfo with oauth2_fetch_user_details=true, we sometimes want to disallow account creation if an attribute is not fulfilled.
This commit adds a new register oauth2_basic_required_json_path which will kick in when retrieving userinfo.
It is a configuration error to set oauth2_fetch_user_details to true but leave oauth2_user_json_url empty.
Before, this resulted in an unhandled exception in core. Now it is checked here.
As we’re upgrading Discourse to Rails 7+, we’re also renaming and moving
some files to better follow Rails conventions on that matter.
The current `require_dependency` call prevents us to do that and is not
necessary as the file referenced here is part of the autoload path.
Other plugins can tell the authenticator to traverse the user details JSON using custom paths and store the values in the user associated account extra field.
Some identity providers send email_verfied as a 'true'/'false' string, not a boolean. (e.g. this bug in Auth0: https://community.auth0.com/t/27553)
This commit adds automatic handling for this case, so that the string is automatically converted into a real boolean.
- Remove Faraday version check - all versions of Discourse now have Faraday 1.0
- Remove custom button CSS. Core now takes care of styling login buttons
- Remove deprecated `message` parameter from auth_provider registration
If specified, the oauth2_authorize_signup_url will be used when the user starts the auth flow via the 'sign up' buttons in the UI. If not specified, the regular authorize_url continues to be used.
This is achieved by surrounding a key with double quotes, or by escaping
the dot character with a backslash.
For example, given the JSON
```
{ "www.example.com/uid": "myuid" }
```
Previously, there was no way to access this value. The dots would make
the parser try to access `json["www"]["example"]["com/uid"]`.
Now, this value can be accessed by using a `oauth2_json_user_id_path` like:
```
www\.example\.com/uid
```
or alternatively:
```
"www.example.com/uid"
```
By default we include both authentication data in both the Authorization header, and in the request body. This provides maximum compatibility, although is technically a breach of the OAuth2 specification. This commit introduces a new site setting `oauth2_send_auth_body`, which allows the behavior to be controlled.
This makes use of Faraday middleware to log precise details about all requests made by the OAuth2 gem. This should make it easier to debug configuration issues
This brings the plugin in-line with recent core improvements. Advantages include
- Account-linking logic and storage is shared between all authentication providers
- Optionally, users can be allowed to disconnect/reconnect their accounts
- The 'last used' date of an association is recorded
- Association metadata is recorded in the database for use in data explorer and other plugins
Data migration will be performed automatically, and all existing functionality is maintained.
* Add way to use user details returned in token response
* Add spec
* Apply suggestions from code review
Co-Authored-By: Robin Ward <robin.ward@gmail.com>
I feel like this is kind of a hack to handle a change with Auth0 where
the actual user id is inside of an array of identities. While I do think
it would be good to build an actual plugin for Auth0 to better handle
their use case I do feel that it is important that we can handle Auth0
with this plugin for now.