1

I've recently started developing e-commerce app with multiple types of users, and currently I am experiencing some issues with browsers Page Cache. Here is one example for user authentication

  1. Authentication Token is generated

  2. Authentication Token is written into the database

  3. Authentication Token and its expiry is saved into the user session

I wrote middleware that checks if user is authenticated and if its authorized (checks the token and access level) as well as expiry - tested it, it works. On "Log Out" I am destroying a session and renewing the token with Session.Destroy(r.Context()) and Session.RenewToken(r.Context())

Here is the problem:

  1. I log in as "Admin" and go to DASHBOARD page for which only admin users are authorized to access.

  2. I logout

  3. I login as regular user and click "BACK' on browser it takes me to Dashboard page when it should not. But, when I refresh the page it does say "UNAUTHORIZED" which is what I was expecting when clicking "back" or something.

I was searching through the internet and found a "solution" where I set the headers in the following manner:

 w.Header().Set("Cache-Control", "no-cache, private, max-age=0")
  
  w.Header().Set("Expires", time.Unix(0, 0).Format(http.TimeFormat))
  
  w.Header().Set("Pragma", "no-cache")
  
  w.Header().Set("X-Accel-Expires", "0")

This however, does not work for me. I do see these headers in the NETWORK card when I open my Web Developer Tools, but problem remains.

enter image description here

What am I doing wrong?

Stefan Radonjic
  • 1,449
  • 4
  • 19
  • 38
  • 1
    It is not a problem, it is correct behaviour with a locally cached page. – Vorsprung Oct 16 '21 at 16:07
  • Is there any way to prevent it? Or are you saying if I push this on a live server "problem" will go away? – Stefan Radonjic Oct 16 '21 at 16:13
  • 4
    This is not a Go thing, it's a browser thing. You might try the solutions presented in https://stackoverflow.com/questions/43043113/how-to-force-reloading-a-page-when-using-browser-back-button. Adding `no-store` to your `Cache-Control` looks promising – erik258 Oct 16 '21 at 16:24
  • 1
    but it is not a problem. If an unauthorised user ever sees that page if they try and do anything that is an interaction with the server (including background javascript calling API) then it will 401. @DanielFarrell suggestion of no-store might work but really, relax it isn't a problem – Vorsprung Oct 16 '21 at 16:32
  • 3
    Tangental question - why is your login a GET request? Logins should probably handled with a POST request so the username and email can be passed in the post body. POST operations also have different caching behaviors in browsers You're not going Back as far as the login page, so I don't think that's relevant to back button behavior. If the sign out page was a POST the browser would probably ask you to approve of resending the POST request ... but that might not be the behavior you want either – erik258 Oct 16 '21 at 16:34
  • Thanks for the help guys! No-store seems to partially solve my issue. But, it is still occurring to some extent, which is odd. Anyhow, to answer @DanielFarrell question. I have a GET for the template rendering handler and a POST when user is submitting the FORM. – Stefan Radonjic Oct 16 '21 at 19:19
  • 1
    Okay, that's just not showing on your web logs. I see what you're saying though, just because you visitied /login doesn't mean a POST was submitted – erik258 Oct 16 '21 at 19:49
  • Yeah, exactly. I should have given a better name of the route probably. – Stefan Radonjic Oct 16 '21 at 19:55

0 Answers0