0

I'm interested in disallowing the following after logout:

-- no back button

-- no direct access to pages via URL - for example: if the user logs out then they should not be allowed to see a cached page using some URL (e.g., replacing the URL with a valid URL in the site http://mysite.com/Gotothispage.aspx)

I've seen similar questions like this one: How to disable the back button in browser when user logout in asp.net c#

I know that I can set no cache on the master page, but then I lose the ability to use the back button when the user is actually logged in. Am I correct in this understanding?

Community
  • 1
  • 1
Arthur Frankel
  • 4,695
  • 6
  • 35
  • 56

3 Answers3

2

A page is either cacheable or it isn't, the browser has no idea if you are logged in or not. You can't somehow retrospectively expire objects already cached by the browser.

Ben Robinson
  • 21,601
  • 5
  • 62
  • 79
  • good point and understood - I'm trying just to avoid the situation where another user goes to a specific URL of the previous user (after the previous user logs out) and can see a cached page - which has sensative data on it. – Arthur Frankel Jun 29 '10 at 19:03
0

Pages should already be disabled after logging out, if your security is setup correctly.

If you have a master page or basepage class specifically for users that are logged in, you should check if they have a sessionId that you set when they logged in.

If they don't, redirect them to another page.

Users may see a cached version of a page, but can't do anything to it.

In my basepage class for members, i check if they are logged in on the OnInit event:

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);

    if (!IsLoggedIn)
    {
        Response.Redirect("default.aspx");
    }
}

Edit:

What some sites do is..after you log the person off, they redirect you to a temporary purgatory page that says it is logging you off. This purgatory page will have caching turned off, and has a meta-refresh tag that takes you to your destination page.

So when the user clicks on the back button, it takes them to the purgatory page which then directs them right back to where they were.

Gmail does this, but sometimes it's so fast you can't tell.

Ed B
  • 6,028
  • 3
  • 26
  • 35
  • Seeing the cached page is the problem - ie, if a user was using a shared machine and logged off the site, another person could use that machine and click back through the history and view some pages. – Damien Dennehy Jun 29 '10 at 18:24
  • Yes, Damien made the point better than I did originally - this is what I'm trying to avoid. – Arthur Frankel Jun 29 '10 at 19:04
0

Then I lose the ability to use the back button when the user is actually logged in. Am I correct in this understanding?

Not entirely - you'll have problems using the back button on pages that are submitted using POST, but not GET.

A simple example would be to imagine an ASP.NET page with a paged Gridview - the user clicks pages 1,2,3,4,5, etc to navigate the grid.

Using POST, every time the user clicks another page in the grid, it will cause a postback to the same page. A page expired error will appear if the user clicks back after doing this.

Using GET, every time the user clicks another page in the grid, it will redirect them to the same page using a querystring (ie, Grid.aspx?Page=2). In this case, the user can click back, and it will take them to the previous page without any problems.

Damien Dennehy
  • 3,937
  • 2
  • 19
  • 21
  • Unfortunately this is an already "built" system and lots of code related to postbacks and such. Also the "pretty" (smaller - no parms) URLs are highly prefered. – Arthur Frankel Jun 29 '10 at 19:05
  • So after re-reading replies again (thank you all BTW) it seems like my only choices are 1) let the user see the cached page; or 2) set no-cache on the pages, keep using POST, and this will disallow a user going back to pages using the browser; or 3) set no-cache, change to GET? – Arthur Frankel Jun 29 '10 at 19:10