Nodejs redirect to intended URL after login

As I continue to recreate my website in nodejs, I find myself going back to my old topics and responses to refresh my memory on how I set things up in php and adapt it to nodejs.

In my current todo to accomplish, I need to redirect a user back to the page they were on after they get successfully logged in.

I reviewed the following topic:

However, this solution does not appear to work in a nodejs project because the redirect is on the server side, not the client side.

I need advice how to redirect a user to the page they were on prior to being directed to the login page. To further complicate matters a little bit, I use the Facebook Auth, so its not a typical login form, rather just an anchor button.

You have the referer url available in $_SERVER.HTTP_REFERER

So if page A redirects to page B(your login) you can then redirect them back to A as it’s stored in the referer header.

Edit: Actually after a second thought I think this won’t work as the restrict redirect happens on server so that http header will not be set as it comes from the browser.

You could however store in a server session variable the url($_SERVER.URL) you navigated to just before the restrict happens and then redirect to that after a succesful login.

I receive the following error when using the $_SERVER.URL:

{“status”:“500”,“message”:“Http status code 400. {“error”:{“message”:“This authorization code has been used.”,“type”:“OAuthException”,“code”:100,“error_subcode”:36009,“fbtrace_id”:“Ab7wxb5nLwUXfh9wPJObOOa”}}”,“stack”:“Error: Http status code 400. {“error”:{“message”:“This authorization code has been used.”,“type”:“OAuthException”,“code”:100,“error_subcode”:36009,“fbtrace_id”:“Ab7wxb5nLwUXfh9wPJObOOa”}}\n at IncomingMessage. (/opt/node_app/lib/oauth/index.js:95:39)\n at IncomingMessage.emit (events.js:327:22)\n at endReadableNT (_stream_readable.js:1221:12)\n at processTicksAndRejections (internal/process/task_queues.js:84:21)”}

I think it is because I use the Facebook Auth, it is redirecting back in a loop after being approved.

Here’s my server action.

$_SERVER.URL will redirect to itself, so causing a loop. $_SERVER.HTTP_REFERER is a better choice. Also you need to store it on the first visit and then retrieve it again on the second visit when coming back from the login. Logic can be a bit difficult, it is easier to just redirect the user to the index page after they logged in.

There are situations where this wouldn’t work very well. Eg during a checkout process, where someone can log in if they an account; going back to the index page having logged in wouldn’t be a good option. There are many similar situations.

I mention this because this type of thing is not much of a problem with PHP. Is it fundamentally more difficult using NodeJS? I have yet to start using NodeJS but at some point, I would like to experiment with it.

1 Like

Did anyone figure out a good way to do this? I don’t have the $_SERVER.HTTP_REFERER avaiable when redirecting through the Security Restrict

Hi @karh,

Are you using Nodejs or php?

I can not tell from your post above, or from Route picker in Security Restrict not allowing me to pass query param

Ah sorry: Nodejs

Here’s how to do this in node:

Inside the API that you use to apply the security restrict, you can save $_SERVER.PATH_INFO in a session variable. You only do this if the user is not logged in and you do it before the security restrict is applied.

Then on successful login you need to redirect the user to that path if that session variable exists and remove the session variable. For example, in mine I output a redirect_path after a successful login:

I then do a browser.goto on success of the login form:

4 Likes

why the fook am i not getting this to work… :frowning: :frowning:

… EDIT… weird… when i call up $_SERVER.PATH_INFO i get nothing… let me see … ill do it again…

For troubleshooting set a value to just $_SERVER and tick output. It will show you all the available variables.

1 Like

thank you… is there any quick hack :slight_smile: to get the “?id=93” to show as well.
I have a large site with about 300 server actions that was dont in php back in the day… but i dont have to time to redo the routes and links to /profile/93 , so my url is profile?id=93 …
with $_SERVER.PATH_INFO it gives me the URL… but not the ?id=part…

EDIT!.. or i might just be forced to do all the routes over… and relink all of it… eishhhhhhhhh

UPDATE… Busy redoing all the routes… not fun… but hey… its needed… and thanks for this great solution… :slight_smile:

Thanks, @mebeingken - it works like a charm.

In the login API action - I amended the condition for the session value to look something like {{$_SESSION.page_ref.length()>1}}. This ensures that if there is no session value, then it takes the user to the dashboard.

I must say that these little tips are great, and thank you to every community user adding tips and tricks.

3 Likes

I know this topic is a bit old but I’m struggling with this. I have the setting of the session in my security_check but where do I check for the session variable? If I try to do it in a condition on the security form success I get an error so suspect I’m doing this in the wrong place?

Thanks.

You cannot access $_SESSION variables on the front-end, you can only access inside a Server Action.

The Server Action should return a trip_id (e.g. Set Value step, with that expression $_SESSION.trip_id inside), and then that way you can access the trip_id coming from the Server Action on the front-end.

I figured out how to get this to work but not sure if it’s correct. I didn’t use a Session variable though.

This is the link…
image

On my main page I have the Server Side Data set to my security check…

Then in the security check I use the $_GET to get the trip_id and then pass that back to the login page…

That goes back to the login page with the trip_id in the url…

image

And then on my login page I use the App/Define Query Parameters to get the trip_id

And then redirect in the onSuccess of my login form…

This is different to what was done above, but it works. Is there any issue with doing it this way?
Thanks.

It’s a “less professional” way, but certainly works :wink:

You might want to add a formatter to convert $_GET.trip_id to a number just for security precaution

1 Like

Can you explain why it’s “less professional”? Thx.

Also - what would the security vulnerability be? If something other than a number that corresponds to the trip is passed it just goes to the users default trip.