NodeJS - Does Security Restrict Redirect from SC?

[mikkime23]

Hi all,

This has been happening since I started this project about 12 months ago however I’m only addressing it now.

So, as expected with Nodemon, every time I save a file, Nodemon restarts the app, thus making the current session void. However, I’ve never been able to get the Security Restrict in any of my SC Actions to actually redirect back to my /public route.

Checking DevTools, I get the following:

My Security Restrict looks like:

---

Am I missing anything here. I’ve searched the Wappler forums for this, and followed @George’s tutorial how to set up Security Restrict on Node , but I can’t seem to find where I’m going wrong.

Any help in the right directions would be greatly appreciated.

Cheers
Michael

[Apple]

@mikkime23

I’ve never been able to get the Security Restrict in any of my SC Actions to actually redirect back to my /public route.

Another Wappler experienced the same issue - I don’t actually know if this is a bug or not, someone from the team will have to answer

In the documentation it says to use the SC Action as a Server Side Data, and in that case, it does redirect

[mikkime23]

Hey @Apple,

The SC action has been connected to my layout page since starting this project.

I’ve been able to get the 401 Unauthorized response by removing both the Forbidden and Login redirects in the Security Restrict, but that now means reloading the userDetails SC on an Action Scheduler, then using the browser component to redirect.

I’m starting to suspect there may be something in my global settings that’s not correct.

OR potentially my routes.

[Digo]

I’m seeing a very similar issue on my node project. Using server-side data does redirect if not logged in, however, normal server connects don’t seem to do this, and they also don’t redirect if authorized which is really annoying. Likewise, I can’t work out if this is a bug or not, but it worked correctly on my old PHP project.

Using the something like dmx-on:unauthorized="dmxBrowser.goto(/401)" also doesn’t seem to work for me. Interestingly, if it’s a security restrict in a server connect I do see in my browser console getting the page, but not redirecting - the same as you do.

[mikkime23]

@Digo

Using the something like dmx-on:unauthorized="dmxBrowser.goto(/401)"

This I have been able to get working. Just remove the redirect paths in the Security Restrict worked for me. However, I don’t want to have to add this to every single Server Connect module on the front-end.

[Teodor]

Not sure what are you guys doing here, but here’s how to protect your nodejs pages: Applying Security to your NodeJS pages

no need of unauthorized events and redirects on your pages. The redirect paths are defined in your security server action, included on the page.

@mikkime23

Note that in Wappler 4 you define your security provider under globals, not in your server action as a separate step!

[mikkime23]

Hey Teodor,

My security provider is defined under globals, however, does the Provider in the screenshot not need to be there that points to the one in globals.

Regardless, in any of my server connect actions, and if you look at the devtools screenshot, the Restrict is that is supposed to be redirecting to my /public route is returning the HTML of the route under the XHR tab, not redirecting the browser there.

[Teodor]

@mikkime23

however, does the Provider in the screenshot not need to be there that points to the one in globals

No…
You need just the restrict step in your server action. That’s the whole point of having the security provider in the globals, to define it once globally.

[Digo]

Yes, this works but only on that the action set as server-side data. Shouldn’t it still work on other server connects? Otherwise, I don’t see why it would be showing in the XHR tab and not redirecting as mentioned by @mikkime23.

Seeing as I only have one layout page, It doesn’t seem productive to make additional layouts for every page I need an unauthorized redirect (loading the contents of the page doesn’t matter so much in my use case, but there does need to be a redirect).

[Teodor]

@Digo

but only on that the action set as server-side data.

You only need one server action to check the logged user. When you try to open a page protected by it, then it redirects the unauthorized users.

[Digo]

Yes - that works, however, not if you have pages that should only be accessible by a certain permission. In that case, as I understand it, you’d need additional layouts/server actions for each page that needs protecting by a different permission.

That’s why I’d prefer to just keep my one layout with one server action that checks for logged in users, then have other pages redirect to 401 when they do not have the correct permission when loading a server connect, something that I assume should work since its in the XHR tab.

[Teodor]

Sorry, not sure I understand your use case. The security restrict will work when used in your page as explained in the doc above - redirecting unauthorized users from the protected page.
Isn’t that waht you are doing? If not, then what?

[bpj]

The server-side binding does protect the page and is the only place where the redirect action has any effect.

What the restrict step is also useful for is to protect API endpoints or prevent access to unauthorised users to data on pages where there may be mixed roles/permissions. The use of conditional regions offers some protection but restricting the endpoint is absolutely necessary. To this end, the restrict step works but DOES NOT redirect users, needing an unauthorised/forbidden dynamic action instead.

It is worth noting, though, that content pages each have their own server-side binding in NodeJS and can all use the same layout.

[Digo]

Well I don’t really want to Hijack this thread, but I guess it might be relevant to both of us.

Keeping things simple:

• My site is completely private and requires an invite. I have 24 pages.

• All of those pages have the same layout assigned to them, which has a server action to check if they are logged in as described by the Applying Security to your NodeJS pages doc.

• However, some pages should only be accessible to people with a certain security provider’s permission. Rather than having additional layouts for all of these pages, I’m just wanting the server connect to redirect them to /401 if they do not have the required security provider permission. This should be simple to achieve by just having a security restrict in the server action. When it’s loaded, and when they don’t have permission, it should redirect them to the forbidden URL set in the security restrict - but it doesn’t, it only shows in the XHR tab.

Which I guess is the main question in this thread regardless of my specific use case, since I’m not sure what the OPs is. Should the security restrict redirect to the set Forbidden URL when not set as the server-side data action, just as a normal server connect on the page like it does in PHP projects? Because for me, and the thread OP, it only shows in the XHR tab instead of redirecting.

[Digo]

It is worth noting, though, that content pages each have their own server-side binding in NodeJS and can all use the same layout

Okay, well this is interesting, because I don’t have this option on content pages, only on layouts.

[Teodor]

@Digo

This should be simple to achieve by just having a security restrict in the server action. When it’s loaded, and when they don’t have permission, it should redirect them to the forbidden URL set in the security restrict - but it doesn’t, it only shows in the XHR tab.

Which server action? A random one included as a server connect component on the page? If that is the case - this won’t work.

[bpj]

@Digo

I don’t have this option on content pages

It should be there if you click on the App element:

[Digo]

Yeah, I can confirm this is not there for me.

[Digo]

That’s correct, well that clears that up for me then. It’s just very strange why it shows in the XHR tab instead of redirecting which is what caused my confusion and why I replied to this topic since I was seeing a similar result. I guess this might also clear up the OPs issue?

But knowning the option for server-side data should be there on content pages should resolve the issue for my use case, but since it’s not there this is a whole new issue now.

[bpj]

Make sure in code view of the page that the meta tag for ac:route comes straight after the commented page setup:

It can sometimes get muddled in the page and I’ve found it sometimes gets in the way of the App settings. @Teodor it might be worth someone making sure it is always ordered on save to be at the top of the page.