dev|sushi

I ran into this issue a couple of weeks ago and have been itching to throw together an article about it. I initially suspected that it was a bug that was causing the problem but now I realize the truth. When you force a page into “Downlevel” mode using the ClientTarget property of the <%@ Page %> tag .Net doesn’t use cookies anymore. Out of the box forms authentication is done using session tracking via cookies and thus you are unable to log in.

One option is to not use “Downlevel” on the login page so that .Net will successfully give the user a cookie and they can proceed into your application. If you try this you will notice that users can not log out if you have the sign-out page using “Downlevel” too since .Net can’t expire the cookie. A work-around for this problem is to create a sign-out link instead of having the sign-out ability on every page. This way you can still use “Downlevel” in your application without blocking user sign-out. The following code is signout.aspx:

<script runat="server">
  Sub Page_Load()
    Session.Abandon()
    FormsAuthentication.SignOut()
    Response.Redirect("login.aspx", True)
  End Sub
</script>

Thankfully even when your page is in “Downlevel” mode it can still access the Session variables based on the Session ID in the user cookie. So reading cookies is no problem in “Downlevel” mode just writing to them. The main reason for using “Downlevel” is to stop .Net from using client side validation so what are our options? Is there a different way to achieve this? How about changing how “Downlevel” functions?

Upon inspection all the browser configuration information exits in C:\WINDOWS\ Microsoft .NET\ Framework\ v2.0.xxxx\ CONFIG\ Browsers in various files. The “Downlevel” configuration is a clientTarget alias that points to “Generic Downlevel” which exists in the generic.browser file. I believe that if you change the cookie setting to “true” then restart IIS you will have cookies working in “Downlevel” mode. However, I did not test this since I don’t believe this is a very good option. The browser detection is a pretty complex hierarchy and it is best not to mess with it. Imagine that one day a user visits that actually maps to “Downlevel” on one of your other applications but then is given cookies what will happen? The browser will likely discard the cookie but the full repercussions are not simple to determine. There is more to “Downlevel” than cookies so from now on I won’t be recommending its use.

How about forcing server side validation? Absolutely! Although I could not find an application wide method you can set the EnableClientScript property of each validator control to “false” which will force the control into server-side validation mode.

What to take away from this article? Well the issue of using ClientTarget=”Downlevel” is more complex than simply causing all controls to use server-side validation in one statement so it is best not to. Take the extra time to set the EnableClientScript=”false” for each validator and save yourself the issues involved with the ClientTarget method.