OAuth2 Basic Support

Thanks @angus, that’s merged now

3 Likes

I’ve just submitted another (somewhat larger) PR here that allows OAuth2 implementations to use user information returned in an access token response.

There’s a detailed description of the context and changes in description of the PR on GitHub.

3 Likes

I just wanted to check in and see if this was possible at all. From a little experimentation it looks like the “SSO overrides groups” doesn’t do this, which makes sense, but it’d be read if we could use our Auth0 provider to be able to automatically set groups in the same way that SSO does.

@eviltrout Would you be open to a PR to this plugin moving the storage of auth provider user reference details from the PluginStore to UserAssociatedAccount (including a data migration for existing implementations)?

I’m finding the need to use both the provider id and the auth credentials (i.e. the access token) outside of the user authentication context. For example, in one case I need to fetch user details outside of the user authentication context to verfiy a logged-in user continues to hold an active account on the provider.

Additional items, such as the credentials, could just be added to the existing PluginStore implementation, however it feels like a good moment to move over to the standardised UserAssociatedAccount.

If not, I’ll make a PR to add the credentials to the existing PluginStore implementation.

2 Likes

This plugin is on our list to be migrated, although we haven’t scheduled the work yet. If you would like to submit a PR that would be great :raised_hands:

4 Likes

@david PR made!

8 Likes

This is great - thanks @angus! I’ve just merged the PR :tada:

6 Likes

I submitted a pull request to add an option to always override usernames. What should I do to get it merged?

1 Like

This plugin has just had a major overhaul, so I’m afraid your PR has a lot of conflicts. Now that the plugin uses the “ManagedAuthenticator”, you would need to make a PR to core (adding a default false “always override all” method to the ManagedAuthenticator class). And then you would make a second PR to this plugin, to override that method with a site setting value.

Take a look at how the “always override email” setting now works, as an example.

5 Likes

Thanks for this awesome plugin, we have integrated it and now our users don’t have to remember a different account for our community forum.

I was looking into a bug we were seeing, with default avatar settings, the avatar is being re-written every login.
If you set a custom picture upload, it’s persisted.
When you log out, then log back in with oauth2, the avatar is reset to the one controlled by the setting external_system_avatars_enabled (The one with just the user initials)

After putting some logging in, I noticed user.rb after_save is being called after login every time, and as such refresh_avatar is called.

I tried to look at this page to see if this is an existing bug, but can’t find anything.
So I looked at the github repo for this plugin, and it’s still v0.3 at the top of plugin.rb, but the code is very different to what we have.

I guess I can only get support if I’m on the latest code of this plugin, how can I know when it is safe to patch my servers to the latest code for discourse-oauth2-basic?
Have you seen this avatar reset bug before?

Thanks so much :slight_smile:

I updated our main discourse to 2.4.0beta2 and installed the latest discourse-oauth2-basic plugin code, and the issue with “avatars resetting on oauth2 login” is resolved.

3 Likes

Hi! There was a problem configuring the plugin. If there is an checkbox “Check this if the OAuth 2 site has verified the email” users are logged, BUT each subsequent, even with another e-mail hits the account first. And if the Daw costs, checking e-mail and other data passes successfully, BUT after clicking register says: incorrect username or mail password. Why?

Any news on this (oauth2_overrides_username)? We need it to maintain one-to-one integrity with our Identity server.

2 Likes

FYI, I installed the plugin on a fresh copy of Discourse today and right away before I set anything up in Settings, I had the following error:

Deprecation notice: (oauth2_basic) full_screen_login is now forced. The full_screen_login_setting parameter can be removed from the auth_provider.  At /var/www/discourse/lib/plugin/instance.rb:571:in `public_send`

That is not an error, it’s a

also know as a “developer warning” that a setting now is not necessary anymore and can be removed in a future version.

3 Likes

Yes I know, that’s why I put it here so you the developer would know. :slight_smile:

Anyway to allow OAuth and 2FA?
If 2FA is enabled it forces username password logging

Yes that’s correct, when you’re using an external provider we delegate all responsibility for authentication to them. If you need two-factor authentication with OAuth, then it should be implemented on the identity provider.

6 Likes

Can you lock the username like the email field is locked with the verified email checkbox?

I don’t want the user to be able to change the username from the oauth provider.

Had I read the thread I would of saw this. It seems im not the only one needing this.

Can any suggest even a temporary hack to disable the username field like the email field is?