Suppose a login link is created as

example.com/user?destination=node/2

in a normal drupal site it would redirect the user to example.com/node/2 after a successful login.

Can't SSO do the same as well?

Currently it does this

example.com/user?destination=node/2

will be redirected to

example.com/?destination=node/2

after successful login.

In singlesignon_controller_user_form_submit can we not process $_GET['origin'] and extract the destination querystring and use that to build the full destination URL instead of redirecting to $_GET['origin']. Is there some reason why this is not being done so?

CommentFileSizeAuthor
#4 sso-respect-destination-and-redirect-807104-4.patch1.62 KBjimmyko
#1 807104-sso_respect_destination_querystring.patch738 byteszyxware

Comments

zyxware’s picture

zyxware commented
StatusFileSize
new 807104-sso_respect_destination_querystring.patch738 bytes

I have attached the patch that does this

sukr_s’s picture

sukr_s commented

need further change to the patch. if the user tried admin/build on the client site, then the redirection fails. the argument must be decoded

 $origin = $parsed['scheme'] .'://'. $parsed['host'] .'/'. $argument[1];

must be changed to 

 $origin = $parsed['scheme'] .'://'. $parsed['host'] .'/'. urldecode($argument[1]);
davemybes’s picture

davemybes commented

This only partially works. I can get back to the node now, however, any fragment (e.g. #comments) to redirect to a specific part of the node, is not carried over. So instead of seeing the comments part of the page, you are taken to the top of the node.

jimmyko’s picture

jimmyko commented
Status: Active » Needs review
StatusFileSize
new sso-respect-destination-and-redirect-807104-4.patch1.62 KB

I tried to look into the patch of #1 and found that it only support one query argument in URL. It is trouble if I need more other arguments. So I have modified the code to add support for multi-arguments

What's new in this patch:
1. support multi-arguments in query
2. add support to #redirect attribute of user form object.
3. followed suggestion of #2

I suggest everyone should follow the name convention of patch stated at http://drupal.org/patch/submit#patch_naming