Redirect back to original page after logging in

judgej

I am using proxyconnect on a closed-user site (no public access) and it is working okay apart from one thing: sending users to the page they wanted after logging in.

When a user receives an email notification of a comment on one of their discussions, the email includes a link to that comment. On clicking the link, the user is taken to the Vanilla comment page, and immediately redirected to the external CMS login page, if they are not logged in.

Now, in that redirect, nothing is passed across to the CMS to tell it where to come back to after the user has successfully authenticated themselves. All the login page can do, is take the user back to the home page of the Vanilla forum. The user has now lost the page they just tried to access, and is frustrated.

I think this works slightly differently in open sites, i.e. where all posts are viewable to the public. Clicking the "login" link will take the user directly to the CMS login page and the REFERER global contains the original page they were accessing.

So, is this fixed in any version of proxyconnect, or is there a workaround or obvious thing I could do to fix this? Ideally, the "login url" could be given some placeholder where the return URL will be inserted by proxyconnect as a GET parameter value (suitably URL-encoded) before sending the user to that login page. Perhaps this can be done already, but I have not yet found the documentation?

Any help appreciated.

-- Jason

judgej

Okay, I've hacked this myself. It required a patch to both core and to ProxyConnect. Both patches are small, but I suspect that may overlook some things that are not an issue to my setup.

The first hack is in the core dispatcher. When Garden.PrivateCommunity is set, a redirect is performed to the default authenticator Gdn::Authenticator()->SignInUrl($this->Request). The "Target" sent to the authenticator ($this->Request) is set to "discussions". I replaced this with the current URI instead, e.g. discussion/123/foobar, taken from the $Request->GetRequestArguments()['server']['REQUEST_URI'] value. This ensures ProxyConnect is told where to redirect to after authentication.

Next I needed to fix ProxyConnect so that it used the Target it was given and passed it to the external login page. In the ProxyConnect plugin, just before the redirect to $SigninURL I add the Target (various kludgy assumptions here, including the fact that the signin URL already has GET parameters, also Target itself contains nothing that needs to be URL encoded):

if (isset($_GET['Target'])) {
$SigninURL .= '&Target=' . $_GET['Target'];
}

Then finally in my external CMS login page I make sure the user is sent back to Target (passed as a GET parameter) after the user logs in.

That works for me, but though it may be useful to others. Ideally, ProxyConnect should be updated to support Target by default. Perhaps it could insert the target into the sign-in URL by replacement of some label, {TARGET} or something.

Secondly, the PrivateCommunity redirect should be changed in core to pass the Target to the authenticator. Without that, there is no way a private community can know where to send a user after they log in, and would always default to the home page, which is more than useless when users click on a link in a discussion notification email.

judgej

Okay, can this be taken as a feature request in ProxyConnect to support "Target" if it is supplied? The idea would be to pass the target into the login URL where indicated, e.g. my CMS login URL may be:

www.example.com/my/cool/login?redirect_url={TARGET}

and the target would be URL encoded and inserted in place of {TARGET}

I'll raise a bug in connection with the core redirect to the login page:

https://github.com/vanillaforums/Garden/issues/872