RSS

Tag Archives: Response

Browser Back button issue after logout

Problem description:
I have found a lot of people asking for a resolution to handle the browser’s back button once user has logged out. Typically, users reports something like:

I am facing issue in my application’s logout scenario. After the user login into website, he/she uses it(website) and when done, they do a logout, which leads them back to login page. But the problem is now, from this login page, if I click the browser back button then it again takes the user back to the previous visited page as if logged in. How can I stop user from viewing the previous page once logged out?

Assessment:
The browser Back button is an option to go back to previously visited pages. The back button can be considered as a pointer that is linked to the page previously visited by the user. Browser keeps a stack of the web pages visited as a doubly-linked list.

The back button works by stepping through the history of HTTP requests which is maintained by the browser itself. This history is stored in browsers cache that consists of the entire page content with resources like image and scripts. This enables browser to navigate backwards and forwards through the browser history and have each page displayed instantly from cache without the delay of having it retransmitted over the internet from the server.

Just to handle the scenario of getting page content from server, browsers have a Refresh button transmits the request to web server and get back the fresh copy of entire page. Internally, this also replaces the copy of the page in the browser’s cache.

Thus, basic reason behind the problem in discussion is Browser’s Cache!

Possible Resolutions:
On Logout, one does clear the session to make sure user related data no more exists. Now, browsers cache needs to be handled such that browser has no history (this will make back/forward button in browser grayed out disabled.) Here are various ways of how one can do it:

Option #1:  Set Response Cache settings in code-behind file for a page

// Code disables caching by browser.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
Response.Cache.SetNoStore();

Option #2: Set META tag for HTTP cache settings in your ASPX page header

<META Http-Equiv="Cache-Control" Content="no-cache"/>
<META Http-Equiv="Pragma" Content="no-cache"/>
<META Http-Equiv="Expires" Content="0"/>

Option #3: Clear browser’s history through JavaScript using script tag

//clears browser history and redirects url
<SCRIPT LANGUAGE="javascript">
function ClearHistory()
{
     var backlen = history.length;
     history.go(-backlen);
     window.location.href = loggedOutPageUrl
}
</SCRIPT>

Option #4: Clear browser’s history through JavaScript injecting through code-behind file via Response

protected void LogOut()
{
     Session.Abandon();
     string loggedOutPageUrl = "Logout.aspx";
     Response.Write("&lt;script language='javascript'&gt;");
     Response.Write("function ClearHistory()");
     Response.Write("{");
     Response.Write(" var backlen=history.length;");
     Response.Write(" history.go(-backlen);");
     Response.Write(" window.location.href='" + loggedOutPageUrl + "'; ");
     Response.Write("}");
     Response.Write("&lt;/script&gt;");
}

Option #5: Clear browser’s history through JavaScript injecting through code-behind file via Page.ClientScript

Page.ClientScript.RegisterStartupScript(this.GetType(),"clearHistory","ClearHistory();",true);

Conclusion:
Any one or combination of above can be used to handle the scenario.

Though, I would like to call out that it’s not a good thing to mess with browser’s history. One should implement it, only if they really need it and are prepared to accept that it is not a good practice. Lastly, few would not work if one disables JavaScript.

Advertisements
 
2 Comments

Posted by on January 31, 2013 in ASP.NET, JavaScript

 

Tags: , , ,

Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack

Problem description:
This is one of the common runtime error reported by a lot of ASP.NET users. A successfully compiled code at runtime throws the following error during an operation:

“Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.”

Typically, this happens when the Response.EndResponse.Redirect, or Server.Transfer method is used.

Assessment:
This happens because current page execution is stopped and execution is sent to the Application_EndRequest event in the application’s event pipeline.

The duty of Response.End method is to stop the page execution and raise the EndRequest event. Thus, the line of code that follows Response.End is not executed. Error occurs with Response.Redirect and Server.Transfer methods too because both the methods call Response.End internally.

When a call is made to the Abort method to destroy a thread, the CLR throws a ThreadAbortException. It is a special exception that can be caught, but will automatically be raised again at the end of the catch block. When this exception is re-raised, the CLR executes all the finally blocks before ending the thread.

Using Visual Studio debugger, we can see the internal message for the exception as “Thread was being aborted.”

Resolution:

  • Use a try-catch statement to catch the exception if needed
    try {
    }
    catch (System.Threading.ThreadAbortException ex){
    }
  • For Response.End : Invoke  HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event
  • For Response.Redirect : Use an overload, Response.Redirect(String url, bool endResponse) that passes false for endResponse parameter to suppress the internal call to Response.End
    // code that follows Response.Redirect is executed
    Response.Redirect ("mynextpage.aspx", false);
  • For Server.Transfer : Use Server.Execute method to bypass abort. When Server.Execute is used, execution of code happens on the new page, post which the control returns to the initial page, just after where it was called.

Refer:
Microsoft Support Article – 312629
MSDN: HttpResponse.Redirect Method
MSDN: HttpResponse.End Method
MSDN: ThreadAbortException Class
MSDN: HttpServerUtility.Execute Method

Conclusion:
This is as designed. This exception has bad effect on Web application performance, which is why handling the scenario correctly is important.

 
1 Comment

Posted by on January 27, 2013 in ASP.NET

 

Tags: , , , ,