Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After the authorization has been made, the access token is being inserted with no type property (which defaults to being 0 -- so OAUTH_COMMON_TOKEN_TYPE_REQUEST), when it should be inserting type = 1 (OAUTH_COMMON_TOKEN_TYPE_ACCESS). The code:
$token->uid = $user->uid;
$token->authorized = 1;
$token->services = $context->authorization_options['default_authorization_levels'];
$token->write(TRUE);
Added this line before the write method is invoked, fixed it:
$token->type = OAUTH_COMMON_TOKEN_TYPE_ACCESS;
(Sorry I don't know how to make patches)
Comment | File | Size | Author |
---|---|---|---|
#4 | 1424470-d7-oauth-change-token-type-on-authorize.patch | 768 bytes | miqmago |
#5 | 1424470-d7-oauth-change-token-type-on-authorize.patch | 1.4 KB | miqmago |
#3 | 1424470-oaut-change-token-type-on-authorize.txt | 525 bytes | miqmago |
Comments
Comment #1
jobeirne CreditAttribution: jobeirne commentedThanks for the issue, edu. Can you describe the pathological behavior that crops up because of this exclusion? I'm not sure what to test for.
Comment #2
miqmago CreditAttribution: miqmago commentedOne pathological behavior I found is when a user wants to see his authorized tokens he can't because of the query in oauth_common_get_user_provider_tokens() in oauth_common.module line 408:
called by oauth_common_page_user_authorizations() in oauth_common.authorizations.inc line 3:
Comment #3
miqmago CreditAttribution: miqmago commentedHere it goes my first patch... hope it is ok
Comment #4
miqmago CreditAttribution: miqmago commentedNeeded to be also added on oauth_common_form_authorize_submit(). Invalidates #3.
Comment #5
miqmago CreditAttribution: miqmago commentedAfter #4 now it shows the authorized tokens in /user/xx/oauth.
If there are multiple request tokens (not yet authorized) and authorized tokens, shows each authorized token as many times as authorized + unauthorized tokens)
Repeat:
1 - request token
2 - authorize token #1
3 - request token again
4 - go to /user/xx/oauth
there will be token #1 twice, because of INNER JOIN in:
Attached new patch with all updates, converting INNER JOIN to LEFT JOIN.
Comment #6
miqmago CreditAttribution: miqmago commentedOk, after testing the whole process, this there is another problem:
When the app tries to get access token from the authorized token, the authorized token needs to be still a "request" token, not an "access" token, if not OAuth doesn't find the token in OAuth.php:
So maybe the question is: when should the user be able to see his authorized tokens, inmediatly after authorizing them, or after the access token has been requested?
Anyway, should #5 be applied in order of not showing multiple lines for same authorized token?
Comment #6.0
miqmago CreditAttribution: miqmago commentedadded code tag