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).
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.
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.
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?
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.
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.
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.
Which server action? A random one included as a server connect component on the page? If that is the case - this won’t work.
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.
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.
What is selected in App Structure for you?
There should be a content page properties section in the Properties panel when on the content page and App is selected:
I’m clicking on App, but I think the issue is that the Wappler include doesn’t exist on my pages?
Maybe I’m not remembering this correctly, but I’m sure I saw a bug report about this ages ago. I just created a new content page and the include is there and I see the content page properties on it, but obviously, it doesn’t exist on my older pages.
So I’m now in the process of manually copying this over to all my other pages to get it to show. I would’ve never known these properties were meant to exist, so thanks for that.
Hi Teodor,
So, I’ve set up another one of my Server Connect Actions without the Security Provider and only the Restrict.
What this action does is calculates fees through a custom module of mine. I click a button, and the fees are calculated and returned. All done through a Server Connect element.
In the following GIF, I have already invalidated the session by saving a file in Wappler. I try to run the SC, and it rightly doesn’t run but comes back with a 302 Found status. Then you see the /public route returned in the Fetch/XHR as stated in my restrict. As you’ll see, there is no browser redirection. Only that it returns the HTML from the route.
Below is what the same page looks like in a valid session.
The Server Connect action that this refers to:
So my question is that if a session becomes invalidated for whatever reason, and a SC is loaded, the Server Connect action will not redirect because it’s through a Server Connect Component? Thus actually NEEDING to set up a Dynamic Event on the SC Component for Unauthorized etc to get a redirection.
I will add that the Server Side Data is set on the page to my userDetails SC Action, and trying to navigate to the page with an invalid session does redirect to the /public route.
Yes, it will only redirect your actual page when the server action is used in the Server Side Data section of your content page. For other server actions included on the page you don’t need the redirect urls entered in the restrict step.
Potential feature request, or is this not a possibility?
I don’t think that is possible, because of the way server action is included on the page(s).
But why don’t you create a restrict server action which checks the login/user data and use in the Server Side Data on your page? When the user is not logged in then he won’t ever see the page, but will be redirected to the login/unauthorized page.
I suppose 99% of the time, a user’s session invalidating will be login timeout, which I haven’t even looked into yet. So for the time being, I’ll have to add dynamic bindings to those SC components I have that are not autoloaded, but user initiated.
This seems like a perfect use case for:
Set up default redirects when forbidden/unauthorised, show errors when something fails…
