Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

ASP.net and browser history

Options
  • 24-03-2009 12:08pm
    #1
    John_Mc
    Registered Users Posts: 2,791 ✭✭✭


    Hi,

    I have a problem where using Response.Redirect on a landing page fails to load that landing page into the browsers history. So clicking the browser back button will skip that page and bring the user back to the page before that.

    The basic scenario is that the user logs in, they're redirected to Default.aspx which looks up which page they should land on and then redirects them to that. However, if the user clicks the back button, they're taken straight to the login page.

    Any ideas how to rectify this?


Comments

  • Options
    #2
    Draupnir
    Registered Users Posts: 3,548 ✭✭✭Draupnir


    Why can't you just decide which page the person should land on at the point where they log in? It seems to me that you have an extra step in the process that is unnecessary.


  • Options
    #3
    John_Mc
    Registered Users Posts: 2,791 ✭✭✭John_Mc


    Draupnir wrote: »
    Why can't you just decide which page the person should land on at the point where they log in? It seems to me that you have an extra step in the process that is unnecessary.

    There are a number of things that need to be performed after login and prior to the user being able to use the system.

    I also wish to prevent the user from accidentally logging themselves out by clicking the browser back button so this landing page is neccessary.

    Thanks for your input


  • Options
    #4
    Evil Phil
    Registered Users Posts: 7,468 ✭✭✭Evil Phil


    Its been my experience that using the approach of trying to control user behaviour is never good. If they log themselves out they can always log themselves in. You can code your logic to ensure that the user doesn't log themselves out when they use the backbutton. The things that need to happen between logging in and using the system could (should?) all be part of the log in process.


  • Options
    #5
    John_Mc
    Registered Users Posts: 2,791 ✭✭✭John_Mc


    Evil Phil wrote: »
    Its been my experience that using the approach of trying to control user behaviour is never good. If they log themselves out they can always log themselves in. You can code your logic to ensure that the user doesn't log themselves out when they use the backbutton. The things that need to happen between logging in and using the system could (should?) all be part of the log in process.

    I think there's a misunderstanding here, we arent trying to control user behaviour at all. It's actually to the contrary!

    A particular client has raised an issue with the behaviour of our web application when the back button is clicked. It uses AJAX Update panels to provide partial page rendering, so when a user mistakenly clicks the back button in the browser (we have provided back buttons in our application), the user is returned to the Login page.

    The Login page then logs the user out on page load (I am told this is for security reasons and will not be changed). I have found a solution around this using a free third party Update History control, but am unsure how much work is involved in fully implementing it.

    So in the short term, I'm looking into ways of either confirming the logout to the user or disabling the back button in the browser. Haven't had any success so far, and I'm beginning to think I should just set about implementing the third party control.

    My OP was about using an intermediate page going one way between the Login page and the homepage. If the user clicks back the they're redirect back to the previous page.


  • Options
    #6
    Ginger
    Registered Users Posts: 2,931 ✭✭✭Ginger


    Response.Redirect uses the HTTP response code 302

    eg

    HTTP 1.0 302 Object Moved
    Location
    http://server

    So the browser will then ignore the previous address

    You can possibly check for if the page is not a post back (ie login) and check for a token (session) and send them back to where they are supposed to go

    Depends on your requirements

    Alternatively you can look at Server.Transfer as your redirect method


  • Advertisement
  • Options
    #7
    Draupnir
    Registered Users Posts: 3,548 ✭✭✭Draupnir


    John_Mc wrote: »
    I think there's a misunderstanding here, we arent trying to control user behaviour at all. It's actually to the contrary!

    A particular client has raised an issue with the behaviour of our web application when the back button is clicked. It uses AJAX Update panels to provide partial page rendering, so when a user mistakenly clicks the back button in the browser (we have provided back buttons in our application), the user is returned to the Login page.

    The Login page then logs the user out on page load (I am told this is for security reasons and will not be changed). I have found a solution around this using a free third party Update History control, but am unsure how much work is involved in fully implementing it.

    So in the short term, I'm looking into ways of either confirming the logout to the user or disabling the back button in the browser. Haven't had any success so far, and I'm beginning to think I should just set about implementing the third party control.

    My OP was about using an intermediate page going one way between the Login page and the homepage. If the user clicks back the they're redirect back to the previous page.

    This is an inherent problem with modern web technologies (AJAX.ASP.NET being a prime example) and legacy usage of the internet. I am afraid you won't really avoid back button issues until you can train users to avoid the back button.

    I've experienced these problems myself with reasonably large websites and found it difficult to get around. I would advise that you improve your navigation to eliminate the need/use of the browser back button, that way you can always tell your customer that their usage is the problem.

    Other than that, as posted above, server.transfer can help and also, there are methods of injecting into a pseudo browser history using hidden frames etc. but they are hacks really.

    I feel your pain, I had this type of thing weekly for about 2 years of my life!


  • Options
    #8
    Draupnir
    Registered Users Posts: 3,548 ✭✭✭Draupnir


    John_Mc wrote: »
    I think there's a misunderstanding here, we arent trying to control user behaviour at all. It's actually to the contrary!

    A particular client has raised an issue with the behaviour of our web application when the back button is clicked. It uses AJAX Update panels to provide partial page rendering, so when a user mistakenly clicks the back button in the browser (we have provided back buttons in our application), the user is returned to the Login page.

    The Login page then logs the user out on page load (I am told this is for security reasons and will not be changed). I have found a solution around this using a free third party Update History control, but am unsure how much work is involved in fully implementing it.

    So in the short term, I'm looking into ways of either confirming the logout to the user or disabling the back button in the browser. Haven't had any success so far, and I'm beginning to think I should just set about implementing the third party control.

    My OP was about using an intermediate page going one way between the Login page and the homepage. If the user clicks back the they're redirect back to the previous page.

    I've worked with that UpdateHistory control, it doesnt work very well and is buggy.


Advertisement