On login, redirect the user back to where they were

Consider a web app having 2 pages: /home and /form .
There is also a login page /login .

Both pages require the user to be logged in. To achieve this, both these pages have the “Content Page Properties” -> “Server Side Data” -> “Server Connect” field selected to “/user” server action. The /user server action has a “Security Restrict” action.

Assume that the user went to one of the pages /form or /home directly, without being logged in.

The “Security Restrict” on the /user API redirects the user to /login .

When the user logs in, on the success of the login action, how do I take the user back to the page where they came from?

If the user had reached the /login page by being redirected from /home, then after login, I want the user to be taken back to /home.

This is usually achieved by attaching a “return_to” URL parameter to the /login page when the “Security Restrict” redirects the user. On successful login, the login page can read the “return_to” GET param and redirect there.

But I am unable to figure out how to send the “return_to” param to the /user API . Could someone help me achieve the above objective?

Here’s how I handle this on node:

Within a Server Side Data > Server Connect, on the protected content page or layout, if the user is not logged in, I save the page that the user attempted to load in a session variable.

Then after a successful login I check for that session variable and set a value that is output back to the login form and remove the session:

On success of the login form, use a browser goto and set its value to the redirect path:


Interesting approach.
Will check.

Question: is there any specific reason why you’re using RUN - browser1 instead of redirect?

I don’t believe that will work:

Works just fine in my case in NodeJS


I would assume then that you are calling your api directly (as would normally be done in an Oauth flow,) which is different from calling it via xhr/ajax.

Thanks @mebeingken . The key information in your post was $_SERVER.PATH_INFO .

One additional thing I want to do is: if the page requested by the user is “/form?utm_source=twitter&utm_medium=paid_social”, then I want the redirect to happen to “/login?utm_source=twitter&utm_medium=paid_social” .

To do this, I needed to know what other variables are available under $_SERVER. So, I added a “Set Value” step, and logged the $_SERVER variable to the console. I saw that there is a “QUERY_STRING” property of the $_SERVER object. I then used it to set the URLs in the “Security Restrict” step.

Thanks for pointing me in the right direction!

I replicated this method, thanks for sharing!
However for some reason in my case the $_SERVER.PATH_INFO value is the path to the server connect action for restricting pages /api/LoginRestrict, and because of that so is the value set for the redirect_path.
Got any idea what’s wrong here?

Any idea @mebeingken? I did exactly as you described, but even in the console I can’t see the session value being set.

It works with {{$_SERVER.HTTP_REFERER}} by the way, but then the set page_ref value is the login page path, not the restricted page’s path from which is redirected to login.

Thanks for any help.

It’s difficult for anybody to provide help when you don’t provide any code or screenshots.

1 Like

Okay you’re right Ken, so here we go:

This is the server connect action for the security restricted pages:

As you can see I added the set page_ref session action there if the user is not logged in.

Further, on the login form server action, I added the set value action to return the redirect_path value to the form on successful login:

Finally, on the login form Success event I set a browser.alert (for testing purposes instead of a browser redirect) that outputs CustomerLogin.data.redirect_path.

This is the alert when the page_ref session is set to $_SERVER.PATH_INFO:
Which is the Security Restrict server action url.

And this is the output when the page_ref session is set to $_SERVER.HTTP_REFERER:
Which is the login form page to which the user was redirect from another Security Restricted page.

Hope this helps to figure out what’s not right here.

Oh and probably needless to say I was logged out while testing and clicked a link to a security restricted page after which I was redirected to the login page :slight_smile:

This might be the key. The use case I built for is an external link – something like a link in an email/sms/social post, etc.

Is your link using the Internal option? If so, I can see where that changes the equation. Try without.

Thanks for the reply Ken!
No, it’s not an internal link. I tested with (dynamic) links to several restricted pages, but also by just entering the link in the browser (like an external link).