Server side data rendering not working properly

I have two layouts. Each layouts are supposed to display based on user authentication. So I used Server side data on appconnect of the layouts. At first, they are working properly no issues there. But if you visit that layout again by using the browser’s back button then it is not redirected.

Example: If a user is logged out from the home page then he/she is redirected to login layout. If the user clicks the back button of browser, then he goes back to home page which is displayed. But it should not be displayed because the user is not authenticated. Keep in mind that, when I visit the different layout I refresh the page.

How can I fix this ?

We have a similar issue (Node/Docker/Windows 10). On back the user is not re-directed and authentication still seems in place, after a couple of refreshes the re-direct activates. Have entered an older site to see if this was the case but am re-directed immediately. Maybe worth a bug report @derick.007

The browser back is always a bit strange since it tries to restore the previous state of the page. When you come from a page with a form you will notice that the form is still filled in when you press back, same with the scroll position which is being restored. Not sure what is the exact problem in your case, but you probably want to disable the back button after the logout.

It could also be caching from the browser, does it show the correct page after you refresh the page? You should force refresh without cache (in chrome windows CTRL+F5 and chrome OSX CMD+SHIFT+R).

How can I disable browser back button ?

When I go back from login page, I get home page which must be protected.

Isn’t control refresh a manual process ? I want secured server datab when I go back ?

@derick.007 You can do this using a little JS. Quick search will reveal many solutions:

@patrick We use Incognito mode for testing so shouldn't be caching. Also on older Projects going back returns the user directly to the login screen, Incognito or otherwise. Several refreshes resolve the issue. Maybe it's a recent Chrome thing? But then, should be the same on the older Projects..?

In incognito it still caches the page, it only reserve separate disk space for its cookies, history and cache which get removed again after the tab is closed.

I will do some testing, can you explain how you have setup your logout flow. I suppose that you probably have a logout server action that you call and then redirect the user to a new page.

There is no good solution for the problem of going back after a logout.

a) You disable back button -> Bad UX
b) You instruct the browser not to cache the protected pages -> It might be an undesired solution.

It is a known problem that cache can display user data even after logout. Only solution is to disable the cache or to disable the back button (history). It may not be good UX, but for securing the data it is the only way.

https://sites.google.com/site/bughunteruniversity/nonvuln/cached-content-after-logout

@patrick

Is there any way to set a Condition based on Content-Length? For example if Content-Length == 0 set a 401 response?

@patrick How can I disable cache control for secured pages in Nodejs ?

We currently don’t have a way to do this within Wappler. We are checking for options, probably we could add it to the route properties for NodeJS.

Is there any way that I could handle this, I can’t seem to find any solution, this is a very crucial requirement.

As a workaround, could you have an SC action on page load/ready (if they fire from using the back button - I’ve not tried) or via scheduler that runs every 10 second or so that simply checks for a security provider identity using a security restrict step? If it’s not found then use the browser component to do a redirect or, possibly better, some JS using window.location.replace (which would prevent the user being able to use the back button again)

Alternatively, when running the SC action to log out use window.location.replace on success

<script>
function gotologin(){
window.loaction.replace("YOUR_LOGIN_URL");
}
</script>
<dmx-serverconnect id="sc_checklogin" url="../api/checklogin" dmx-on:unauthorised="run({runJS:{function:'gotologin'}})"></dmx-serverconnect>
<dmx-scheduler id="scheduler1" dmx-on:tick="sc_checklogin.load(true)" delay="10"></dmx-scheduler>

Why wouldn’t an authorized user that saw private data just a few seconds ago be allowed to see that same data by clicking back button? What is your use case?

I am concerned about the breakdown that might occur while working on authorized functions.

And worst case scenario it does not have to be the authorized person that is going back.