[bd] API 1.6.3

[lwn]

Works! Thank you very much for replying so fast

 

[lwn]

I'm currently creating a new Oauth2 backend for python-social-auth - http://psa.matiasaguirre.net for Xenforo bd API. Implementing this is fairly straight forward. However I'm running into trouble when I'm requesting a token at oauth/token. It's giving me a response: '{"error":"invalid_scope"}'. I'm giving the scope when first redirecting the user as following:

/api/index.php?oauth/authorize&?scope=read+post&state=nOC4sRtzvbIVojJtLdZ6Ma4BrzxGpd32&redirect_uri=http%3A%2F%2Fxxxxxx.xx%3A8000%2Fcomplete%2Fxenforo%2F%3Fredirect_state%3DnOC4sRtzvbIVojJtLdZ6Ma4BrzxGpd32&response_type=code&client_id=uofp7kgopv

(I'm seeing the 'Authorize Access' page, but the requested permissions are empty.)

What is going wrong here?

 

[Milano]

Could you please add Newsfeed to this add-on ? That would be great

 

[xfrocks]

I'm currently creating a new Oauth2 backend for python-social-auth - http://psa.matiasaguirre.net for Xenforo bd API. Implementing this is fairly straight forward. However I'm running into trouble when I'm requesting a token at oauth/token. It's giving me a response: '{"error":"invalid_scope"}'. I'm giving the scope when first redirecting the user as following:

/api/index.php?oauth/authorize&?scope=read+post&state=nOC4sRtzvbIVojJtLdZ6Ma4BrzxGpd32&redirect_uri=http%3A%2F%2Fxxxxxx.xx%3A8000%2Fcomplete%2Fxenforo%2F%3Fredirect_state%3DnOC4sRtzvbIVojJtLdZ6Ma4BrzxGpd32&response_type=code&client_id=uofp7kgopv

(I'm seeing the 'Authorize Access' page, but the requested permissions are empty.)

What is going wrong here?

Probably a problem with sending the scope in your URL, particularly this part:

?oauth/authorize&?scope=read+post

Should be...

?oauth/authorize&scope=read+post

 

[xfrocks]

Could you please add Newsfeed to this add-on ? That would be great

The newsfeed system relies a bit too much on the template system, make it hard to include in this add-on. I will see what I can do

 

[Milano]

The newsfeed system relies a bit too much on the template system, make it hard to include in this add-on. I will see what I can do

I know but add-on devs should create newsfeed templates with their add-ons, because the newsfeed system relies on Newsfeed class handler too.

 

[lwn]

Probably a problem with sending the scope in your URL, particularly this part:

Should be...

Works like a charm now! Thanx for your help in finding that (silly) mistake.

 

[Skiphs]

I'm very new to the whole OAuth2 system, so sorry if I'm overlooking something very simple.

I can't seem to find a use for the client_secret. It seems that I'm able to make a request for authorization, or tokens without providing the client_secret at all. Am I doing something wrong? Or does the secret have a different use?

 

[xfrocks]

I'm very new to the whole OAuth2 system, so sorry if I'm overlooking something very simple.

I can't seem to find a use for the client_secret. It seems that I'm able to make a request for authorization, or tokens without providing the client_secret at all. Am I doing something wrong? Or does the secret have a different use?

You need the secret to exchange the authorization code for access token.

 

[Skiphs]

You need the secret to exchange the authorization code for access token.

Maybe I'm doing something wrong?

I'm using
https://SITE_URL/api/oauth/authorize?client_id=CLIENT_KEY&response_type=code&scope=read post usercp conversate
Which gives me back a code, but when I go to submit that... I just provide the code, grant_type, client_id, and it still returns back my access token.

Additionally, it seems if I use: response_type=token, that works as well. (Once approved it gives back an access token without using the client_secret ever)

 

[xfrocks]

Maybe I'm doing something wrong?

I'm using
https://SITE_URL/api/oauth/authorize?client_id=CLIENT_KEY&response_type=code&scope=read post usercp conversate
Which gives me back a code, but when I go to submit that... I just provide the code, grant_type, client_id, and it still returns back my access token.

Additionally, it seems if I use: response_type=token, that works as well. (Once approved it gives back an access token without using the client_secret ever)

For token type, secret is not required. But for code type, you should not be able to get access token without a valid secret. Please confirm your finding, it may be a bug.

 

[Skiphs]

For token type, secret is not required. But for code type, you should not be able to get access token without a valid secret. Please confirm your finding, it may be a bug.

Alright, I ran a simple test. I went to:
https://SITE_URL/api/oauth/authorize?client_id=CLIENT_KEY&response_type=code&scope=read post usercp conversate
Signed in, accepted it, and was redirected to:
http://REDIRECT_SITE_URL/?state=&code=CLIENT_CODE

I then opened up a fresh browser session (Not logged in) and navigated to the SITE_URL.
In the Chrome console I put:

$.post( "https://SITE_URL/api/oauth/token", {
        'code': 'CLIENT_CODE',
        'grant_type': 'authorization_code',
        'client_id': 'CLIENT_KEY',
        'redirect_uri': 'REDIRECT_URL' // Not sure if this is needed
    })
    .done(function(data) { console.log(data); });

(Since javascript seemed to be the fastest way to test my theory)

This returned a json object:
{"access_token":"ACCESS_TOKEN","expires_in":3600,"scope":"read post usercp conversate","refresh_token":"REFRESH_TOKEN"}

Am I just misunderstanding how this should work?
Also, is there a point to a client secret if you could just use response_type=token instead?


Edit:
Also, as an additional bug: If you put a forward-slash in the client key, it completely breaks the admin panel access to it. You can't delete or edit it after that point.

 

[xfrocks]

Alright, I ran a simple test. I went to:
https://SITE_URL/api/oauth/authorize?client_id=CLIENT_KEY&response_type=code&scope=read post usercp conversate
Signed in, accepted it, and was redirected to:
http://REDIRECT_SITE_URL/?state=&code=CLIENT_CODE

I then opened up a fresh browser session (Not logged in) and navigated to the SITE_URL.
In the Chrome console I put:

$.post( "https://SITE_URL/api/oauth/token", {
        'code': 'CLIENT_CODE',
        'grant_type': 'authorization_code',
        'client_id': 'CLIENT_KEY',
        'redirect_uri': 'REDIRECT_URL' // Not sure if this is needed
    })
    .done(function(data) { console.log(data); });

(Since javascript seemed to be the fastest way to test my theory)

This returned a json object:
{"access_token":"ACCESS_TOKEN","expires_in":3600,"scope":"read post usercp conversate","refresh_token":"REFRESH_TOKEN"}

Am I just misunderstanding how this should work?
Also, is there a point to a client secret if you could just use response_type=token instead?


Edit:
Also, as an additional bug: If you put a forward-slash in the client key, it completely breaks the admin panel access to it. You can't delete or edit it after that point.

Regarding the secret issue, I can reproduce it on my server. It should not do that but the implementation is correct so far. I will need to consult the documentation for OAuth2 for this and will get back to you later. Anyway, secret has other usages too, to generate one time token for example. Maybe they are not required for code authorization (I need to check OAuth2 documentation for this as said above).

For token authorization, it is completely handled in the front-end and the token is expired in a short amount of time (3600 seconds by default), no refresh token is given either. This is documented in OAuth2 paper. Ideally, the secret is not required for JavaScript/mobile app usage because they can be decompiled easily. Only server-server communication requires secret for some of their requests.

Regarding the forward-slash bug, can you give reproduce steps?

Thank you very much.

 

[Skiphs]

Regarding the secret issue, I can reproduce it on my server. It should not do that but the implementation is correct so far. I will need to consult the documentation for OAuth2 for this and will get back to you later. Anyway, secret has other usages too, to generate one time token for example. Maybe they are not required for code authorization (I need to check OAuth2 documentation for this as said above).

For token authorization, it is completely handled in the front-end and the token is expired in a short amount of time (3600 seconds by default), no refresh token is given either. This is documented in OAuth2 paper. Ideally, the secret is not required for JavaScript/mobile app usage because they can be decompiled easily. Only server-server communication requires secret for some of their requests.

Regarding the forward-slash bug, can you give reproduce steps?

Thank you very much.

Yeah, all of my code is server side, I just prefer javascript for debugging things. It makes creating GET/POST requests very easy.

As for the slash bug:
1.) Go to Admin CP -> Tools -> Clients -> +Add New Client
2.) Fill in whatever information you'd like, but for "API Key" put "test/test" (Or any other string with a slash in it)
3.) Attempt to edit or delete this after creation.

It appears the problem is that it treats the slash as part of the path. Here's an example of what the URL would look like if you had set API Key to "broken/link" http://SITE_URL/admin.php?api-clients/broken/link/edit
It may be worth simply adding a client-side validation for that particular field to make sure no slash is included. In my case it was accidental, and I happened to accidentally have deleted it later. (I'm still not sure how I deleted it-- it just disappeared with my other API Client at one point during setting things up)

 

[Skiphs]

...For token authorization, it is completely handled in the front-end and the token is expired in a short amount of time (3600 seconds by default), no refresh token is given either. ...

Forgot to mention, it does appear that I'm getting a refresh token when using response_type=token. If I understand what you're saying, I shouldn't be?

 

[xfrocks]

Yeah, all of my code is server side, I just prefer javascript for debugging things. It makes creating GET/POST requests very easy.

As for the slash bug:
1.) Go to Admin CP -> Tools -> Clients -> +Add New Client
2.) Fill in whatever information you'd like, but for "API Key" put "test/test" (Or any other string with a slash in it)
3.) Attempt to edit or delete this after creation.

It appears the problem is that it treats the slash as part of the path. Here's an example of what the URL would look like if you had set API Key to "broken/link" http://SITE_URL/admin.php?api-clients/broken/link/edit
It may be worth simply adding a client-side validation for that particular field to make sure no slash is included. In my case it was accidental, and I happened to accidentally have deleted it later. (I'm still not sure how I deleted it-- it just disappeared with my other API Client at one point during setting things up)

Nice bug. Fixed in development.

Forgot to mention, it does appear that I'm getting a refresh token when using response_type=token. If I understand what you're saying, I shouldn't be?

That shouldn't happen. What is the redirected URI (with fragment)?

 

[Skiphs]

Nice bug. Fixed in development.


That shouldn't happen. What is the redirected URI (with fragment)?

https://SITE_URL/api/oauth/authorize?client_id=CLIENT_ID&response_type=token&scope=read+post+usercp+conversate

Sends me to

https://URL/#access_token=ACCESS_TOKEN&expires_in=3600&scope=read+post+usercp+conversate&refresh_token=REFRESH_TOKEN

(There's also a state that gets passed too, but the site uses that to redirect to the correct page)

 

[xfrocks]

https://SITE_URL/api/oauth/authorize?client_id=CLIENT_ID&response_type=token&scope=read+post+usercp+conversate

Sends me to

https://URL/#access_token=ACCESS_TOKEN&expires_in=3600&scope=read+post+usercp+conversate&refresh_token=REFRESH_TOKEN

(There's also a state that gets passed too, but the site uses that to redirect to the correct page)

Thank you for the information. Looks like this is a misunderstanding on my part. I will update the add-on to require validation of secret.

 

[humanoidfr]

Is it possible to authorize a specific client without making the user go to the authorization page? I would like my users to be able to comment on Wordpress (which would do a POST /posts on Xenforo) without having them to realize Wordpress is a client.

 

[xfrocks]

Is it possible to authorize a specific client without making the user go to the authorization page? I would like my users to be able to comment on Wordpress (which would do a POST /posts on Xenforo) without having them to realize Wordpress is a client.

You (developer) can use password authentication scheme to avoid redirecting user to the authorization page. Or you (admin) can edit the client in AdminCP and auto-authorize needed scopes, user will not see the authorization page when those scopes are requested.