Secure SPA Sites

Since this is my admin back end, I have security restrict on everything. (insert, update, delete, list) I don’t want anyone being able to do anything on my admin back end unless they are logged in and have permission.

I’ve been thinking about this issue a lot, the only thing I can think of is some kind of session solution, but sadly I do not know enough about sessions to come up with a solution.

I have to do some further testing but I think I found a way to keep the user logged in on a secure SPA site.

On my index page (main template) I have a server connect showing the user details of the logged in user. I set a scheduler to reload that query every 15 minutes. It seems to be working to keep the user logged in.

I’m going to test it tonight by leaving it logged in this evening. Come back in a couple hours and see if it is still logged in.

2 Likes

Good idea, I have a get user details query on my index page as well, I’ll add a scheduler to see if it will work for me.

1 Like

Interested to hear the result of this…

You just need to add the security enforcer to the main / index page(s) as those are always loaded and then any routes are filled in with content pages.

So securing those should be enough

1 Like

Using the Scheduler did not work for me.

@George,

Using the security enforcer will secure the page and routes, but the concern is what happens when the session times out.

For example, I have open my SPA page and I am logged in. I leave the browser window open for say an hour and come back to the page. The page will still function, but any database content that is protected by security restrict will be unavailable because there is no longer a valid session. The only solution is refresh the page. Upon refreshing the page, the security enforcer will redirect you to the login page to login again.

1 Like

I’m pretty sure this is true for a “true” SPA too eg. Angular, react, VueJS etc. (Wappler seems to be using the Pjax/Turbolinks technique). So in a regular SPA, you’d get a token from the REST API, store it in a cookie or local storage and send that token with each request to the REST API. The user could leave the page open while the token expires, the “page” will still be interactive, but any requests to the REST API will be invalid. In this scenario, the SPA would then redirect to the login route.
I haven’t tested this in Wappler, but if the session has expired, does it not throw an error that you can catch and in there redirect them to the login route?

Hi Niall,
The logged user session is created on log in like explained here:

You can add a condition and set response if the session has a value or not. Then you can do redirect based on the response.

1 Like

User the scheduler method seems to have worked for me. I logged in, left the page for about an hour and a half, came back and refreshed the page and I was still logged in.

So, is there a way to fire an alert, or better yet, redirect as soon as that session expires?

I’m guessing you could poll this action so if it doesn’t have a value it will automatically redirect the user?

That would be ideal, Niall. I am just not sure how to go about doing that. Interesting concept.

Via Action Scheduler? Just have it run the action @Teodor recommended would be my first guess.

Well, you can check every X minutes by loading the server action via action scheduler.
In your server action add a condition step, which returns the session value.
In the then step add response code 200.
In the else step add response code 401.

On the clientside run the action with the scheduler.

In the server action component > dynamic events on unauthorized (i.e. code 401) run the redirect.

2 Likes

I’m just looking into doing something like this myself and am wondering what’s the best approach to take?

My app is setup as a SPA, I’ve an index, login and register page etc. (which are all SPA).
When a user logs in I want to redirect them to a secure SPA page. Since the Security Provider Enforcer is done at the main page level, I’m guessing that I will need two main Routes; one for the public pages (which will have Page Routes) and another for the “admin” only portion of my app (which will then also have its own Page Routes) but will also contain the Security Provider Enforcer.

Is this the correct approach to take?

Thanks in advance.

@niall_obrien,

That is what I did. I have the public SPA with a user dashboard conditioned on their login and then I have a separate admin SPA conditioned on the Security Provider Enforcer.

1 Like

Thanks for clarifying @scott - just tried it out and have it all working great. :slight_smile:

1 Like

Hi George,
Since security enforcer does not work on .html is it right to make the main /index.php? and can subsequent - content pages also be .php?
Thanks

Sure if you site gets loaded from a web server that runs PHP, you can rename it to .php

1 Like