On a site located in a subdirectory (domain.com/thesite) the destination parameter that is set when a non-logged in user attempts to go to the authorize page incorrectly includes the base directory. The url appears as: domain.com/thesite/user/login?destination=/thesite/oauth/authorize?... After signing in the user is redirected to: domain.com/thesite/thesite/oauth/authorize?...
The attached patch fixes it by not using url() and instead just uses drupal_query_string_encode() to handle the query string.
Not sure if this is related, but whatever issue required it could be retested and it could maybe be removed:
// There's some strange bug in the ?destination=... handling
// This is not exactly beautiful, but it gets the work done
// TODO: Find out why!
if(drupal_substr($_SERVER['REQUEST_URI'], 0, 2)=='//') {
header('Location: ' . drupal_substr($_SERVER['REQUEST_URI'], 1), TRUE, 302);
}
Comment | File | Size | Author |
---|---|---|---|
#7 | oauth-login-destination-922110-7.patch | 596 bytes | chustedde |
#5 | oauth-922110-oauth_destination-5-D6.patch | 561 bytes | christianchristensen |
#4 | oauth-922110-oauth_destination-4-D6.patch | 558 bytes | christianchristensen |
#3 | oauth-922110-oauth_destination-3-D6.patch | 558 bytes | christianchristensen |
oauth-destination.patch | 547 bytes | tauno | |
Comments
Comment #1
voxpelli CreditAttribution: voxpelli commentedThis seems to somehow be related to #1184672: Double url encoding on destination=/oauth/authorize? when redirected to log in form - right?
Comment #2
toemaz CreditAttribution: toemaz commented@tauno could you test the patch at #1184672 and see whether that fixes your issue?
Comment #3
christianchristensen CreditAttribution: christianchristensen commentedI believe this addresses the concern in this issue and #1184672: Double url encoding on destination=/oauth/authorize? when redirected to log in form, as the oauth_callback parameter needs to be encoded once more to allow it to take the form of its original encoding provided by the calling oauth process. Please see patch.
(Edit: oops wrong issue number referenced)
Comment #4
christianchristensen CreditAttribution: christianchristensen commentedSlightly updated from above: urlencode the whole destination parameter.
Comment #5
christianchristensen CreditAttribution: christianchristensen commentedAs noted by @glennpratt (offline/IRC) core uses rawurlencode... see updated patch.
Comment #6
chustedde CreditAttribution: chustedde commentedI also experienced this issue in the D7 version of the module and was able to fix it with a similar solution found in #1184672: Double url encoding on destination=/oauth/authorize? when redirected to log in form.
Comment #7
chustedde CreditAttribution: chustedde commentedUpdated patch so it will properly apply with git.