OAuth2 Basic - Legacy replies

sso
1

So happy to be integrating our discourse instance with our OAuth server. Thank you.

Part 1: I was able to get our OAuth server popping up and go through the user grant flow.

For part 2, the way we GET user data is at the endpoint https://…/users and our access token in provided in the header as follows:

Authorization: Bearer {ACCESS TOKEN HERE}
Accept: application/json
Content-Type: application/json;charset=utf-8

I don’t think we provide the access token as a URL parameter. What advice can you provide?
Thanks for any help in advance.

2

I think I could add an option to support it as an auth header like this as it seems quite common.

1 Like
3

Let me confirm one thing… our instance happens to have a DNS entry of community.zatar.com. Would that make my DISCOURSE_HOST be community.zatar.com too?

In other words, when I register with my OAuth provider, should my entry be “http://community.zatar.com/auth/oauth2_basic/callback” or something else?

4

Yup, that’s correct.

5

Thanks for the suggestion. I’ve added this HTTP header to the JSON request. I tested it with Dropbox as an OAuth2 provider and it worked great. Just get the latest version and you should be good to go!

6

We are using a hosted instance. Will this latest update need to be pushed to our hosted solution or is there a way for me to go get it?

7

If you are hosted by us, the oAuth2 plugin should be available on all Business class hosting plans, I believe @eviltrout already enabled that for the Business container.

8

I can confirm OAuth2 is deployed to all Business customers.

3 Likes
9

Hey Guys. Posted this question elsewhere, but wanted to get it in this thread as well.

Is there a way to adjust the size of the login window when using a custom OAuth2 provider? Default seems to be making an 800x400 window.

10

Don’t think so but it should be trivial to add some site settings for that.

11

Would this solve our earlier query about implementing support for battlenet oauth?

12

I haven’t looked at their implementation, but there is a good chance it could work if you set it up!

13

Some of the fields the plugin requires are obvious enough, but their docs don’t give any hints as to the following:

  • oauth2 user json url
  • oauth2 json user id path
  • oauth2 json username path
  • oauth2 json name path
  • oauth2 json email path

Are all of the above mandatory, or just convenient?

14

They are required. We need a JSON endpoint to retrieve information about the user with the token. (See Part 2 in the original post for more details).

15

Ok, makes sense, in which case it might not be viable, I don’t think Blizzard will return the email for starters.

16

Oops sorry I should have been more clear – the only mandatory field is the json_user_id_path. The others are optional but you need at least one from the JSON endpoint.

1 Like
17

Hi,

I found that there is a piece of code that builds correct basic authorization header for token request:

  def basic_auth_header
    "Basic " + Base64.strict_encode64("#{SiteSetting.oauth2_client_id}:#{SiteSetting.oauth2_client_secret}")
  end

But it looks like this code isn’t called. At least we see that our OAuth 2.0 server doesn’t receive any authorization header with the /token request. Could you please check that authorization header is actually passed to OAuth 2.0 server?

18

It is called just a few lines before in the function that creates the token’s headers.

19

Yes, that’s correct. The problem is that the method build_access_token ain’t called. And as a result the method basic_auth_header is never called either :frowning:

20

Okay I think I’ve fixed it here, can you try the latest version of the plugin?

https://github.com/discourse/discourse-oauth2-basic/commit/27ff369904f1389216e485b4da64b59b45fef671

(It’s hard for me to test as I don’t have a provider which needs that header)

2 Likes