Care, Share and Grow! : ASP.Net

A simple exe to find DEBUG build for managed modules and DEBUG attribute in Web.Config for Web applications in IIS 6/7

Saurabh Singh — Sat, 05 Dec 2009 22:17:00 GMT

CAVEAT: Some stories before I get to the point, so you may want to skip to the end.

We in Microsoft PSS get lot many cases on a daily basis which are related to performance issues with Web applications developed using ASP.Net and hosted on IIS. Based on my experience with debugging these issues many-a-times I have seen that one (or two) very basic step is often missed by our customers. Guess what, they develop the projects/class libraries/modules/assemblies etc (name it whatever you want) and test it thoroughly in the development/testing/staging environments and then go ahead and deploy the same binaries in the Production. What they overlook or tend to forget is that they are deploying the same DEBUG build modules/dlls in the production as against the recommended RELEASE builds/dlls.

Most of us know that for performance reasons it is always recommended to deploy a release build in the production as against a debug build to reap more benefits from compiler optimizations etc. The above observation is generic and applies to any application running managed code.

There is one more thing people often overlook when it comes in specific to IIS ASP.Net Web applications, i.e. DEBUG attribute in the Web.Config file under system.web/compilation tag. This is one setting which has a lot of repercussions on the performance of the Web applications running ASP.Net as a web technology like memory issues, fragmentations, etc.

A very nice detailed tutorial by Rahul (one of our former Technical leads in IIS/ASPNET support group) just reflects what I will never be able to convey any better. Check this link if you want to know more on how this DEBUG attribute may affect your application.

What we often do in support is that we capture memory dumps of the IIS process and analyze it using various tools (most common here being WinDBG). There are some public extensions available to our customers like sos.dll to debug managed memory dumps. However this extension has been deprecated (from .Net 2.0) and it does not have a feature to find out debug modules that were loaded in the IIS process and the value of the debug attribute set in the Web.Config file.

I felt that getting memory dumps from our customers and then finding out the above in their application settings and then recommending them to fix it just adds to the overall delay in finally fixing their core issue. This should be done by default. This is something that does not even need our support in the first place if people are well aware of it.

I wrote this tool just to help reduce their downtime or getting one step closer to their ultimate resolution. I know I write a lot so I will come straight to the point now :).

Point:

Feature 1:

This tool (I rechristened it as DebugFinder.exe) will attach non-invasively to any currently running process on the system and find out if any managed modules that are loaded is a DEBUG or a RELEASE build. This is applicable to any process and not only to Web applications. That way you can find out at run time which managed modules referenced in the current process are deployed as release versus debug builds. This helps keeps track of any debug build assembly that is being referenced from the GAC at runtime apart from the modules loaded from its current working directory if any. Once done it then detaches from the attached process without terminating it.

Feature 2:

We know that it is always recommended to have DEBUG attribute set to false in a Web.Config file in a production server.

This tool scans the machine for the Web applications that are configured in IIS. It looks for the Web.Config files corresponding to all the web applications configured in IIS and checks if they have the DEBUG attribute set to true or false and notifies in the display.

The Debug flag checking in the Web.Config file works for the web applications running either in IIS 6.0 or IIS 7.0/7.5 by this tool.

Pre-conditions:

DebugFinder has to be run locally on the machine where we want to get the debug related details (remotely may be in another version).
It needs .Net framework 2.0 to be installed on the machine for successful running.
Currently it is designed/tested for Win2k3/Vista/Win2k8/Win7 for finding Debug attribute in the Web.Config file.
If we have UAC turned on on Vista/Win2k8/Win7 ensure we run it in the privileged mode.

Here are some screenshots:

Here I have used MdbgCore.dll to attach/detach to a process at run time and show the details for debug modules.

Attached is a zip file, containing a 32bit and a 64bit DebugFinder builds along with MdbgCore.dll. Ensure we keep both the DebugFinder32/64.exe and the MdbgCore.dll in the same folder while running it.

Chill!

Required permissions when calling a Web service using client certificate for authentication in an ASP.NET Web application

Saurabh Singh — Fri, 03 Jul 2009 04:08:04 GMT

A Web service requiring Client certificate authentication is a common scenario.

You may have a client application which needs to send the Client certificate as part of the web request for accessing the web service.

This client application may be a Windows/Console application or another Web application.

Often you will get into issues wherein you are able to send Client certificate as part of the web request from a windows/console app but not from another web app. The primary reason for this could often be around Web app not being able to send the client cert to the target Web service.

This can happen for multiple reasons, in particular account under which Web app is running doesn't have enough permissions to access the Client cert in its local certificate store.

Refer to this excellent kb for this for more details.

In this post I want to highlight ways in which you can grant access to the Web application account to access the Client certificate in its local machine store.

When we have to send client cert as part of the web service call from a web app we need to ensure that the client cert is installed in the Local Computer -> Personal Store on the local box (where Web app is running). By default you will see the client cert installed in the Local User Store for the user who requested and installed the cert on the machine. You need to ensure first that the client cert is installed on the Local Computer Store instead of the Local User Store and then follow any of the methods below to grant access to the private key for the account (under which your web app is running).

Method 1:

The above article kb gives an example of granting access using the Microsoft Windows HTTP Services Certificate Configuration Tool

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a " AccountName "

for e.g.

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a "Network Service"

There are other ways in which you can achieve the same result. This feature is in fact built in on Windows Server 2008 within the Certificate mmc console.

Method 2:

Using the WSE X509 Certificate tool (This tool has features that can be used to check certificate properties).

You need to download Web Services enhancements (WSE) 2.0+ SP3 for Microsoft.Net and in the install wizard ensure you select Tools as shown below:

Once installed go ahead and launch the tool. It has a clean UI. You have the option to check certificates in the Local Computer/Current user for the available stores like Personal/Trusted/Intermediate Root CA etc. If you click on View Private Key File Properties (shown below) you can directly modify the permission for private key associated with the certificate. Basically this is just a file under C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys on Win2k3 server and C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys on Win2k8 server.

You may want to go ahead and give the Service account under which the web app is running Full permission on this file (modify the permissions from the Security tab).

Method 3:

If you are running the web app on Windows Server 2008/Vista there is a far simpler way built in the Certificate mmc.

Right click on the certificate and go to All Tasks -> Manage Private Keys and then give Full permission for the associated account.

Till next time..

Cheers!

Visual Studio 2005/2008 IDE: Web Controls in the Toolbox seen grayed out for Asp.Net projects ?

Saurabh Singh — Thu, 23 Apr 2009 03:28:12 GMT

Here is a quick post that may help you save few hours if you get into this problem.

Symptoms

-- Out of blue you realize that when you try to create and open a new Web site/Web Application project we do not see any of the Web controls in the Toolbox. It includes most of the sections in the Toolbox pane including Common controls, Data, Login, validation and in fact any of the controls which are associated with an Asp.Net web page.

-- When you click on 'Show All' in the toolbox you see all the Asp.Net related controls grayed out. In fact you will see most if not all, of the sections in the toolbox being grayed out except HTML controls.

Go to the Source view for the Web form in the VS IDE and add an ASP control yourself like <asp:TextBox...></asp:TextBox>

Browsing to the web page shows the control getting rendered without any issues. So seems like more of a VS IDE issue than anything to do with ASP.Net application configuration.

-- Creating a new Winform project works fine with all the relevant controls being displayed and working in the Toolbox window.

Resolution

This issue may happen if by mistake you had associated ASPX pages with the HTML Editor in the VS IDE. It should be ideally associated with the Web form Editor.

To resolve this, In the Solution Explorer, locate the ASPX that we are working on, right click on the page and select 'Open with...'.

You may be seeing that the current selection is HTML Editor (Default). Change it Web Form Editor and click on 'Set as Default'.

Close the current VS IDE and re-launch it and now we should *hopefully* be good.

Automate client certificate one-to-one mapping in IIS 6.0 using C#

Saurabh Singh — Sat, 11 Apr 2009 03:04:00 GMT

In PSS, we occasionally get requests from our customers wherein they want to automatically add entries for client certificate mapping in IIS or Active Directory (AD). That is either a 1-to-1, Many-to-1 or AD mapping for the client certificate authentication for the web site. I recommend going with AD mapping because that eases the management but it finally depends upon one's need.

I am not sure but I feel there is a security breach plus annoyance when an administrator has to laboriously enter the mappings for all the accounts/certificates (I am being specific to 1-to-1/Many-to-1 here).

The concern I feel when dealing with the administrator doing it for 1-to-1 and Many-to-1 are:

a. If there are hundreds of users you need to do this manually for everyone of those accounts and it's a pain.

b. Yes, the above can be automated using a script but then the second concern that arises is that whoever is running the script has to know the passwords for all these accounts to be mapped. I think this doesn't sound good.

I have written a sample application using which users can enter the mappings themselves in the IIS's Client certificate setting, i.e. entries having the client certificate mapped to a windows account (either a local IIS or AD account) and the corresponding password.

So this is how it works:

User accesses this web page from their workstation which already has the client certificate installed.
They are authenticated over Basic with SSL.
Browser sends across the client certificate as part of the HTTP web request.
This application gathers the user account, password plus the client certificate from the incoming HTTP web request and does the mapping in IIS.

I am adding the code here in case someone may want to extract the section for automated scripting instead of using it as a web app.

This code is also attached to this post as well.

using System;using System.Data;using System.Configuration;using System.Web;using System.Web.Security;using System.Security.Cryptography.X509Certificates;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Web.UI.HtmlControls;using System.DirectoryServices; /* This sample application is to automate One-to-One Client certificate mapping in IIS 6.0. * User should be able to access this site from the browser and select the client certificate * in their machine which will be mapped to their account on the IIS server for 1-to-1 mapping.  * You need to deploy this application on the IIS server which is hosting the website(s) which  * needs client certificate mapping, preferably under its own virtual directory. * * Important: * - Have the authentication for this web application configured to use Basic along with SSL. * - Have the "Accept client certificates" or "Require client certificates" selected under  *   <Website> -> Properties -> Directory Security -> Secure communications -> Edit -> Client certificates * - Ensure the website that we want the mapping for is mentioned in the web.config file associated with *   this application under <appSettings> * - In the Web.config file we are impersonating an Administrator account for this application.  *   <identity impersonate="true" userName="Administrator" password="myadminpassword"/> *   This is done because non-admin users cannot modify the IIS metabase. If you do not want users to map *   entries themselves through web page you can change this to <identity impersonate="true" />. *   In such a case only admins can add the mappings for their user accounts. Non-admins won't be able to  *   add the client mapping entries. *   This is valid for both domain or local Windows NT accounts. * - This app is written using .Net 2.0, ASP.Net 2.0 and above in mind. You should be able to make it work *   with ASP.Net 1.1 as well. * - You may prefer to run this application under its own dedicated application pool to ensure stability and security. *  * DISCLAIMER: The code is not tested for production scenarios so use it at your own risk.  *             In case one wants to use batch scripting etc or some kind of console app instead  *             of web app you can extract the code section from this page which should work fine for the job. */ public partial class _Default : System.Web.UI.Page {    protected void Page_Load(object sender, EventArgs e)      {        Response.Write("<B>Client Certificate One-to-One Mapping Application:</B><BR><HR>");        Response.Write("Serial number: " + Request.ClientCertificate.SerialNumber + "</BR><HR>");        Response.Write("Issuer: " + Request.ClientCertificate.Issuer + "</BR><HR>");        Response.Write("Subject Name: " + Request.ClientCertificate.Subject + "</BR><HR>");        if (Request.ClientCertificate.IsPresent)        {            Response.Write("Validity<BR>");            Response.Write("&nbsp;&nbsp;&nbsp;&nbsp;Not before: " + Request.ClientCertificate.ValidFrom + "</BR>");            Response.Write("&nbsp;&nbsp;&nbsp;&nbsp;Not after: " + Request.ClientCertificate.ValidUntil + "</BR><HR>");        }        else            Response.Write("<B>There is no client certificate sent along with the request!</B><HR>");         Response.Write("Authenticated User: " + Request.ServerVariables["AUTH_USER"] + "</BR><HR>");        Response.Write("Authentication Type: " + Request.ServerVariables["AUTH_TYPE"] + "</BR><HR>");    }    protected void Button1_Click(object sender, EventArgs e)    {        string user = Request.ServerVariables["AUTH_USER"];        string password = Request.ServerVariables["AUTH_PASSWORD"];        string clientCertMappingName = "Mapping for " + user;  // <--- Our One-to-One Mapping name for the entry        HttpClientCertificate cert = Request.ClientCertificate;        /*          If you want to map a client certificate located on the disk instead of the one as part of the           HTTP Web request try the code below.                    X509Certificate certificate = X509Certificate2.CreateFromCertFile(@"c:\cert.cer");          X509Certificate certificate = cert.Certificate;          byte[] certHash = certificate.GetRawCertData();        */        byte[] certHash = Request.ClientCertificate.Certificate;        try        {        //Get the name of the Web site for which mapping has to be done from the App settings in the web.config file.        string friendlyWebsiteName = ConfigurationManager.AppSettings["websitename"].ToString();         //Get the Site Identifier based on the friendly name of the Web Site.        string siteId = getsiteid(friendlyWebsiteName);         if (siteId != null)            {            string sitePath = "IIS://localhost/W3SVC/" + siteId + "/IIsCertMapper";            using (DirectoryEntry de = new DirectoryEntry(sitePath))            {                de.Invoke("CreateMapping", new object[] { certHash, user, password, clientCertMappingName, true });            }            Response.Write("Account Mapped: <B>" + Request.ServerVariables["AUTH_USER"] + "</B></BR>");            Response.Write("Mapping Name: <B>" + "Mapping for " + Request.ServerVariables["AUTH_USER"] + "</B></BR>");            Response.Write("Web Site: <B>" + friendlyWebsiteName + "</B></BR>");            }        else            {            Response.Write("<B>Web Site does not have a valid Site ID. Ensure we have the correct site name in the config file for this app.</B>");            }        }                catch (System.Runtime.InteropServices.COMException)        {            Response.Write("A COM exception occurred while setting up the mapping.");        }        catch (SystemException)        {            Response.Write("An error occurred while setting up the mapping.");        }        catch (Exception)        {            Response.Write("An error occurred while setting up the mapping.");        }           }     public string getsiteid(string websitename)    {        DirectoryEntry root = new DirectoryEntry("IIS://localhost/W3SVC");        try        {            string siteid = null;            foreach (DirectoryEntry de in root.Children)            {                if (de.SchemaClassName == "IIsWebServer")                {                    if (websitename.ToUpper() == de.Properties["ServerComment"].Value.ToString().ToUpper())                        siteid = de.Name;                }            }            if (siteid == null) return null;            return siteid;        }        catch        {            return null;        }        finally        {            root.Close();        }    }}

Ciao

Nice weekend!

Unable to load DLL 'bcrypt.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Saurabh Singh — Thu, 09 Apr 2009 01:38:01 GMT

I recently had the privilege to get access to a machine from a colleague of mine. It was a Windows server 2003 server and I had to test some ASP.Net application for one of my pet projects. I was focusing completely on the project at hand before I was completely taken off by a surprise, although not a pleasant one.

I found that my application was throwing the following exception, in fact forget my own application even a test Asp.Net 2.0 page having just a one word was failing. Also this happened for web resources hosted directly in IIS. If you run this app from within Cassini (ASP.Net Web server) you may not see this issue at all. This happened for both Website as well as WAP based applications hosted in IIS.

Server Error in '/' Application.
--------------------------------------------------------------------------------

Unable to load DLL 'bcrypt.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.DllNotFoundException: Unable to load DLL 'bcrypt.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Source Error: 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.  

Stack Trace: 


[DllNotFoundException: Unable to load DLL 'bcrypt.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)]
   Microsoft.Win32.Win32Native.BCryptGetFipsAlgorithmMode(Boolean& pfEnabled) +0
   System.Security.Cryptography.Utils.get_FipsAlgorithmPolicy() +140
   System.Security.Cryptography.RijndaelManaged..ctor() +13
   System.Web.Configuration.MachineKeySection.ConfigureEncryptionObject() +232
   System.Web.Configuration.MachineKeySection.EnsureConfig() +156
   System.Web.Configuration.MachineKeySection.GetEncodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32& length) +37
   System.Web.UI.ObjectStateFormatter.Serialize(Object stateGraph) +166
   System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Serialize(Object state) +4
   System.Web.UI.Util.SerializeWithAssert(IStateFormatter formatter, Object stateGraph) +37
   System.Web.UI.HiddenFieldPageStatePersister.Save() +79
   System.Web.UI.Page.SavePageStateToPersistenceMedium(Object state) +105
   System.Web.UI.Page.SaveAllState() +236
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1099

 


--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.3053; ASP.NET Version:2.0.50727.3053

This was quite perplexing as I couldn't find much information on this across the net. One incident I found talked about un-installation of MS07-040 security update. I was running on .Net framework 2.0 Sp2, Windows Server 2003 SP2. No luck with it. I had no clues about this dll which was missing as in the exception and why the heck it was looking for it in the first place.

The interesting part here was that the call stack looked like having some encryption/decryption algorithm (RijndaelManaged) being used perhaps related to viewstate. I finally had to disable the attribute EnableViewStateMac="false" for the web page to make it work, but well that may not be an option all the time for everyone.

If you face such a scenario just don't go ahead with reinstallation of .Net framework 2.0, it may not help you but only drain your precious time.

Analysis/Resolution

From this KB article this is what RijndaelManaged is all about.

"ASP.NET 2.0 uses the RijndaelManaged implementation of the AES algorithm when it processes view state data. The ReindaelManaged implementation has not been certified by the National Institute of Standards and Technology (NIST) as compliant with the Federal Information Processing Standard (FIPS). Therefore, the AES algorithm is not part of the Windows Platform FIPS validated cryptographic algorithms."

To work around this either set EnableViewStateMac to false or else add the following entry as mentioned in the kb under <system.web> section for the web application.

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>

ASP.NET use the Triple Data Encryption Standard (3DES) algorithm to process view state data instead of the AES (Rijndael) algorithm. Remember this is comparatively weaker than Rijndael based encryption and hence your application will be comparatively insecure.

*Note that the error message in the above article is not exactly the same as what I saw here for this post but the resolution remains the same :-).

Till next time..

Asp.Net Request routing implementation fails with Null Reference exception

Saurabh Singh — Thu, 19 Mar 2009 21:33:15 GMT

I recently had the pleasure of working on the implementation of Asp.Net Request Routing feature that comes in bundled with .Net Framework 3.5 SP1. This is a cool stuff wherein care has been taken to ensure it can be used independently of MVC Framework. It can be used with Dynamic Data as well as implemented for any generic Asp.Net 2.0 application for Request routing functionality.

*Remember this is different from ASP.NET 2.0's URL Mapping.

The aim of this post is so obvious for many but I am writing this post because I couldn't get any pointers on this over the Internet, although I know I should have checked the end resolution in the very beginning; silly of me.

We were getting the following exception when we we were trying to route a request. Exception was being thrown from within our custom class implementing IRouteHandler.

Server Error in '/' Application. 
________________________________________
Object reference not set to an instance of an object. 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error: 
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 

Stack Trace: 

[NullReferenceException: Object reference not set to an instance of an object.]
   System.Collections.Generic.Dictionary`2.GetEnumerator() +38
   Mycustomdll.Net.RouteHandler`1.GetHttpHandler(RequestContext requestContext) in C:\abcdedfgh\myprojectforfun\asdfsdf\Net\RouteHandler.cs:37
   System.Web.Routing.UrlRoutingModule.PostResolveRequestCache(HttpContextBase context) +106
   System.Web.Routing.UrlRoutingModule.OnApplicationPostResolveRequestCache(Object sender, EventArgs e) +80
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

This application was failing for one of my customers in his environment. I was finally able to reproduce this problem locally on one of my machines as well. Found that ideally this should work fine if you have the latest build.

On debugging found it was failing at the section shown below in the custom Routehandler class while trying to iterate through the RouteValueDictionary collection even though there were items in the collection. It was failing with the null reference exception.

public class RouteHandler:IRouteHandler
     {
        ...... 
        ......
       public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
             foreach (var value in requestContext.RouteData.Values) <------------
             {
                 .....
             }
             .....
             .....
             return (Page)BuildManager.CreateInstanceFromVirtualPath(VirtualPath, typeof(Page));
        }
     }

You may see this crash behavior if you are running with the build version of System.Web.routing as shown below. I assume this is from the ASP.Net 3.5 SP1 Beta release, not sure.

In order to rectify this issue ensure you move to the latest build for System.Web.Routing.dll as well as for System.Web.Abstractions.dll.

Lesson: Never try to run Beta/CTP version etc. on the production environment. Ensure you have the latest bits deployed.

Programmatically managing Virtual Server using C#

Saurabh Singh — Sat, 25 Oct 2008 04:10:00 GMT

Virtual Server 2005 (VS2005) is a well-known tool to manage Virtual Machines (VMs) on a host server. It is a great feature to manage virtualization for hardware/software. Most often one would use the VS2005 Web Admin interface to manage VMs. But at times (like the way it recently happened for a customer of mine) one may want to programmatically control the VMs. This would most often sound a necessity if you would like to provide end users access to manage basic VM activities like turn on/off, save state etc. etc. without giving them access to everything as in through the VS2005 Web Admin site.

Here are some code snippets/sample web application/links in case you would like to try your hands on something like this.

Let me show you a typical screen-shot of how VS2005 Web Admin interface looks like.

To programmatically manage the Virtual machines on a host server, you need to add a reference to a COM object for your .Net application which exposes various properties/methods.

Visual Studio will add a COM Interop layer for this. You should see the following in your Visual Studio project:

Ensure we add a namespace as "using Microsoft.VirtualServer.Interop;" in the web/form page.

Here are code snippets (in C#) to:

a. Turn On/Restore from a saved state for a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

b. Turn Off a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_Running || vm.State == VMVMState.vmVMState_Paused)
                {
                        // Turn the power off on the Guest VM
                        Label1.Text = "Forcefully shutting down VM...";
                        VMTask vt = vm.TurnOff();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                        else
                            Label1.Text = "Not ready for a turn off. Please wait and try again after a few seconds...";
                 }

c. Save state of a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

d. Pause a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

e. Resume a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

f. Reset a Virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

g. Shut down a virtual machine on a local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

h. Enumerate all the Virtual machines running on the local host machine.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

if (vm.State == VMVMState.vmVMState_TurnedOff || vm.State == VMVMState.vmVMState_Saved)
                {
                        VMTask vt = vm.Startup();
                        if (vt != null)
                            vt.WaitForCompletion(-1);
                }

i. Check various properties exposed through the COM API.

VMVirtualServerClass vs = new VMVirtualServerClass();

VMVirtualMachine vm = vs.FindVirtualMachine(VM_name);

                string _VMName = vm.Name;
                string _guestOS = String.Empty;
                if (vm.State == VMVMState.vmVMState_Running)
                    _guestOS = vm.GuestOS.OSName;
                else
                    _guestOS = "OS: n/a"; 
                string _memory = vm.Memory.ToString();
                .......

j. At times if you want to manage VMs hosted on a remote machine and not on the local machine, here is what you need to do besides all the steps already mentioned above.

private VMVirtualServerClass connectToRemoteHost(string remoteHost)
    {
        VMVirtualServerClass virtualServerCOM = null;
        Type VMVirtualServerClassType = typeof(VMVirtualServerClass);
        try
        {
            // create remote type from class identifier
            Type DCOMType = Type.GetTypeFromCLSID(VMVirtualServerClassType.GUID, remoteHost, true);
            object DCOMObject = Activator.CreateInstance(DCOMType);
            // create local object from remote object
            virtualServerCOM = (VMVirtualServerClass)Marshal.CreateWrapperOfType(DCOMObject, VMVirtualServerClassType);
            TextBox1.Text = String.Empty;
            return virtualServerCOM;
        }
        catch
        {
            TextBox1.Text ="There was an error while connecting to the remote host. Make sure that we have the necessary permissions/settings to access the remote host";
            return null;
        }
    }

(Courtesy this MSDN magazine)

I have not included error handling in the code snippets above. Please do so when you build the actual application. Also there are many other activities that can be performed besides the ones discussed above like setting up a VM from the beginning with various components like differencing, memory, network adapter etc., changing the disk configuration of an existing machine etc. etc.

The more you explore the more you get to control through the code using the API mentioned above.

Here are some useful links related to the topic.

http://msdn.microsoft.com/en-us/magazine/cc163935.aspx

http://dotnet.sys-con.com/node/47338

http://blogs.msdn.com/david.wang/archive/2006/04/17/HOWTO-Perform-VHD-Maintenance-Automatically.aspx

http://blog.anildesai.net/?p=220, http://blog.anildesai.net/?p=214

Attached is a sample ASP.Net 2.0 web application to try the above commands if interested.

Till next time our paths cross.

Bye!

Change in IIS MMC setting may cause unwanted restarts of W3SVC

Saurabh Singh — Tue, 22 Apr 2008 23:31:11 GMT

Recently we have discovered an issue with IIS Manager wherein changing settings in a certain way may cause unexpected restart of World wide Web Publishing Service. And this may happen before you realize until you go back to the Application event log and find entries corresponding to the W3SVC restart event as shown below:

Event Type:    Information
Event Source:    ASP.NET 2.0.50727.0
Event Category:    None
Event ID:    1023
Date:        4/22/2008
Time:        6:35:20 AM
User:        N/A
Computer:    SAURABSI-SEC
Description:
Restarting W3SVC

Event Type:    Information
Event Source:    ASP.NET 2.0.50727.0
Event Category:    None
Event ID:    1025
Date:        4/22/2008
Time:        6:35:25 AM
User:        N/A
Computer:    SAURABSI-SEC
Description:
Finish restarting W3SVC

Also as part of the above symptom, you will see IIS mmc paused like in a hung state (you may see a transient hour glass).
So what are the steps you need to be cautious of especially in a production environment?

First, a little background...

If you intend to change the version of ASP.Net through IIS manager by going to the Web Site properties --> ASP.Net tab, you should be fully aware that W3SVC service will get restarted in order to reflect the change. Restarting of W3SVC will lead to all the application pools getting recycled along with it, hence leading to all your currently running web applications to spawn new worker processes for further requests. This is by design and if you want to circumvent the recycling of other application pools not corresponding to your website, you should have a way to control W3SVC restart after the version change. You can do so by following this excellent post by Jerry Orman.

So far so good. But I have something else to disclose too.

Let's say you go to the IIS manager, select a Web site, go to its properties and poke around with different settings. At some point you visit ASP.Net tab (even if you do not modify any settings like current ASP.Net version) and move out from there to some other tab. On this tab if you do any change(s), and you click on Apply and then OK (in the same order) bang!, your W3SVC service will restart and all your application pools will recycle subsequently as a result of it.

Here are some quick steps to reproduce the problem, follow it to believe it.

1) Open IIS manager (Start -> Run -> inetmgr.exe)
2) Select any website --> right click and select properties
3) Click on ASP.NET TAB - do not change or modify anything - just click on the TAB.

4) Now click on any other TAB and change some values (for example: go to website tab and change port to say 8080 from 80)
5) Hit apply
6) Hit OK
7) This will restart W3SVC and you will see following event in application event logs.

In the above steps the key points are basically to visit the ASP.NET TAB and then click on Apply and then OK to reproduce the issue.

Why is this behavior?
===================
The reason this behavior occurs is in the code where we make a check to see if ASP.NET runtime version is changed and if yes we need to fire W3SVC restart. We are comparing the selected version of ASP.NET TAB with what has been changed incorrectly. There is an additional code in place that checks for the QFE versions of the ASP.NET framework installed, but in the IIS manager UI, we only give an option to either select 1.x.xxxx or 2.0.xxxxx. We really don’t care about the QFE versions installed after that. But the code that gets executed on OK or APPLY does. For the 1st execution (i.e. click on APPLY) it’s correctly able to remove the QFE information from the version string it retrieved (i.e. 2.0.xxxxx, instead of 2.0.xxxxx.QFE), the check is successful noting that nothing is changed in ASP.NET TAB, and hence no restart of W3SVC is required. But now when we go ahead with 2nd execution (i.e. click on OK) the same code executes again and this time the version information string is truncated further to RTM (i.e. to 2.0 from 2.0.xxxxx) and thus the check fails (ASP.Net version is changed from 2.0.xxxxx to 2.0), which incorrectly indicates that ASP.NET runtime version has been changed and thus calls a restart of W3SVC.

In short, you could click anywhere in UI all day long, but for you to reproduce this issue, you need to
1) Go to ASP.NET UI once.
2) Click APPLY and OK (both in that order). If you only click OK then the code gets executed only once and hence correctly and would not restart the w3svc.

Latest update on this:

We have informed the Product group about this issue. A Knowledge base article is in work.

Laterz!
Saurabh

Unable to correctly display Chinese (Unicode) characters in Excel when opened through ASP.Net page

Saurabh Singh — Wed, 27 Feb 2008 04:12:48 GMT

Recently I was working on an issue wherein one of our customers was trying to stream data from their web application in CSV format for it to be recognizable and opened through Excel on the client's end. Basically they were setting content-type and content-disposition to open the file outside the browser and open it in MS-Excel. Everything would have worked had they not used Chinese characters as data in this case.

Something like this:

Page.Response.Clear()
Page.Response.ContentType = "application/vnd.ms-excel"
Page.Response.ContentEncoding = System.Text.Encoding.UTF8
Page.Response.AddHeader("Content-Disposition", "attachment; filename=ExportData.xls")

And later in the code they were reading the column headers and column row in CSV format into a string which will get flushed as a response output.

Something like this:

'Output Column Headers as

columnHeaders = "HEADER1" + Chr(9) + "HEADER2"
columnHeaders = columnHeaders & Chr(13) & Chr(10)

[Here, Chr(9), Chr(10) and Chr(13) correspond to Tab, Linefeed and Carriage Return characters in ASCII respectively to adhere to CSV format]

Page.Response.Write(columnHeaders)
Page.Response.Write(Chr(10))

and

'Output Column Row as
columnRow = ""

After populating the columns in various strings we do this to adhere to CSV format:

columnRow = coulmn1 + Chr(9) + column2

columnRow = columnRow & Chr(13) & Chr(10)

...............

Page.Response.Write(columnRow) ' Finally display the data

Now if you see above this should work if we try to open the file using Excel. Although if we are sending the data in UTF-8 encoding (let's say for Chinese characters), Excel doesn't recognize it correctly and opens it in ASCII. In normal scenarios the above functionality will not cause issues but if we are using any Unicode characters like Chinese the data will be wrongly displayed in Excel. You may see "???????" etc. Although it may display perfectly fine in the webpage control , let's say in a datagrid.

The resolution to such an issue is to switch from UTF-8 to Unicode and add Unicode byte leader
to the start of the file. Excel will recognize the byte-leader as an indication of Unicode data coming in, and correctly read the file as Unicode. This way Unicode characters like Chinese can be preserved when opened through Excel.

Here is something you can try:

Dim rgByteLeader(1) As Byte
rgByteLeader(0) = &HFF
rgByteLeader(1) = &HFE

        Page.Response.Clear()
        Page.Response.ContentType = "application/vnd.ms-excel"
        Page.Response.ContentEncoding = System.Text.Encoding.Unicode
        Page.Response.AddHeader("Content-Disposition", "attachment; filename=ExportData.xls")

' Write out the Unicode header FFFE so that Excel recognizes the file as Unicode()
Page.Response.BinaryWrite(rgByteLeader)

'Output Column Headers as before

columnHeaders = "HEADER1" + Chr(9) + "HEADER2"
columnHeaders = columnHeaders & Chr(13) & Chr(10)

Page.Response.Write(columnHeaders)
Page.Response.Write(Chr(10))

'Output Column Rows as before
columnRow = ""

.............

columnRow = coulmn1 + Chr(9) + column2
columnRow = columnRow & Chr(13) & Chr(10)

Page.Response.Write(columnRow)

.....

Page.Response.End()

I am no Globalization/MS-Excel expert but I had a tough time researching on this issue so thought of sharing it with others. Hope this helps!

How to achieve a feature similar to single logon for multiple web applications using Basic authentication

Saurabh Singh — Fri, 10 Aug 2007 01:23:00 GMT

Here is something which I recently figured out. This may be very simple to many but thought of sharing it for a wider audience.

Let's say you have two ASP.Net web applications running on two different servers.
Now, assuming you have a constraint wherein you cannot use Windows integrated authentication (in cases where in you have some JSP application running on Websphere and another Asp.Net app on IIS server or any multi-platform scenarios), and you want to access the 2nd web app internally from the 1st web app for authenticated users. Now since you cannot use windows integrated authentication (e.g. Websphere doesn't support windows integrated authentication) the only option is to use Basic authentication which is supported across multiple platforms.

So here Windows integrated and anonymous authentication are out of picture and you are left with Basic authentication. Now if you want to access the 2nd Web app internally from the 1st web app and since both are configured for Basic authentication what will you do. IIS prompts for basic authentication and since you are trying to access it internally from the 1st web app you may get into issues wherein IIS will throw 401 Unauthorized error.

1st Web app ---> 2nd Web app
(Basic Authentication) (Basic Authentication)

Had Windows integrated authentication been supported we could have gone ahead with Kerberos but now that is out of picture.

This is what I figured out. If a user is authenticated using basic authentication, an Authorization header is passed (after user enters the credentials and is authenticated) to the server as part of the request header. Now this header will remain the same for a combination of username and password. Web server recognizes the future requests for the same user using the same header.

Now if you try to call the 2nd web app URL through the 1st web app using httpwebrequest you will get 401 unauthorized. This is because the web request from the 1st web app does not send the Basic authentication token to the destination by default. It sends a new request to the 2nd web app and since 2nd web app is configured for basic authentication only and no anonymous authentication it will fail with 401.

To avoid getting into such issues you can modify your code in the 1st web app such that it also appends the Authorization header (which it gets during the first basic authentication done by the 1st server) along with the new http request to the 2nd web app (now all this assuming the user is allowed to access both the websites on both the servers).

Here is code snippet on the 1st web app which calls the 2nd web app internally.

Default.aspx
==============

Default.aspx.cs
===============

Assuming web app2 being http://shrek:8080/default.aspx

Here is the error thrown on the browser:

Now try adding the following lines and browse to the page in web app1. You should be able to access the web app2 without any issues.

Default.aspx.cs
===============

If you notice we are resending the authorization header that we got during the 1st web app authentication process. The same authorization header when accessing the 2nd web app nullifies the requirement for a new authentication handshake between IIS and the its client request. If we did not pass the authorization header to the 2nd web request IIS has to renegotiate a new authentication process with its client in order to get the necessary credentials for allowing access to its contents. Thereby throwing error 401 in our case since we are calling the 2nd web app internally in the code. The above scenario can work for N number of websites which can easily be greater than 2.

Do remember to add resp.close() and reader.close() in the above code section at the end.

If IIS is configured for basic authentication only it will look for Basic Authorization header before serving the request.

Also remember if you use just a response.redirect from 1st web app to 2nd web app it will work just fine but you will be prompted twice for basic authentication. This is because you get prompted for credentials the first time when you access the 1st web app and then again when a new request is sent for the 2nd web app through response.redirect it doesn't have the authorization header by default (Remember response.redirect cause a new request to be sent to the server from the client's end). So IIS again prompts you for credentials.

If it doesn't find an authorization header it will send a 401 response back asking the client to resend the request with a valid authorization header. Here above we are adding an authorization header along with the request in the first place so that IIS need not send 401 response.

***Basic authentication sends credentials in clear text and is base64 encoded. So it can be easily decoded by a sniffer. So its recommended to use SSL with basic authentication.

Accessing Request.CurrentExecutionFilePath property in Response.Redirect Vs Server.Transfer methods

Saurabh Singh — Fri, 20 Apr 2007 12:23:57 GMT

Ok, I understand you might feel lethargic while viewing this blog of mine thinking, here again the same old crap about server.transfer and response.redirect.

Don't know how many links you would already have found if you did a Live or Google on the net on the above commands. I at least found two dozens of them.

So here I am not going to talk not about what they mean but a little weird scenario when it comes to using Request properties like Request.CurrentExecutionFilePath.

We had a customer who had written his own custom HTTP Module which intercepts request and response for Asp.Net pages.

Now, in his HTTP Module, he was trying to access the Request.CurrentExecutionFilePath property. Simple!

The problem arises when you use the above mechanisms, especially using Server.Transfer.

We know that in Response.Redirect the request flows between client and the server until we get the right path for the requested page.

Client Server

GET /redirecttransfer/default.aspx HTTP/1.1 HTTP/1.1 302 Found
Location: /redirecttransfer/Default2.aspx

GET /redirecttransfer/Default2.aspx HTTP/1.1 HTTP/1.1 302 Found

                                                                                                               Location: /redirecttransfer/default3.aspx

GET /redirecttransfer/default3.aspx HTTP/1.1                                      HTTP/1.1 200 OK

So here we have a complete round trip between the server and the client. The Request will have all the information about the requested page, accordingly we should get the right value in Request.CurrentExecutionFilePath (which should be Default3.aspx here). But what happens if you try to read the same property when using Server.Transfer instead of Response.Redirect?

Let's say the request flow is: Default.aspx >>--Server.Transfer--> Default2.aspx >>--Server.Transfer--> Default3.aspx

Now in the HTTPModule under Application_EndRequest method, if we try to display the Request.CurrentExecutionFilePath property, what should we see?

Guess....should it be Default.aspx, or Default2.aspx or Default3.aspx or something else altogether.

Check it yourself, I am adding a sample HTTPModule here:

public class HelloWorldModule : IHttpModule
{
public HelloWorldModule()
{
}

public String ModuleName
{
get { return "HelloWorldModule" }
}

// In the Init function, register for HttpApplication
// events by adding your handlers.
public void Init(HttpApplication application)
{
application.BeginRequest += new EventHandler(this.Application_BeginRequest);
application.EndRequest += new EventHandler(this.Application_EndRequest);
}

private void Application_BeginRequest(Object source, EventArgs e)
{
// Create HttpApplication and HttpContext objects to access
// request and response properties.
HttpApplication application = (HttpApplication)source;
HttpContext context = application.Context;
context.Response.Write("<h1><font color=red>HelloWorldModule: Beginning of Request</font></h1><hr>");
}

private void Application_EndRequest(Object source, EventArgs e)
{
HttpApplication application = (HttpApplication)source;
HttpContext context = application.Context;
context.Response.Write(context.Request.CurrentExecutionFilePath+"</br><hr><h1><font color=red>HelloWorldModule: End of Request</font></h1>");
}

public void Dispose()
{
}
}

Also let's say you have default.aspx, default2.aspx and default3.aspx as shown above in the flow diagram. We do a server.transfer from default.aspx to default2.aspx, which in turn does a server.transfer to default3.aspx page.

Here are the codes:

Default.aspx

public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Request.CurrentExecutionFilePath);
Server.Transfer("Default2.aspx");
}
}

Default2.aspx

public partial class Default2 : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Request.CurrentExecutionFilePath);
Server.Transfer("default3.aspx");
}
}

Default3.aspx

public partial class Default3 : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Request.CurrentExecutionFilePath);

}
}

You will notice that when you try to access the default.aspx page it does the server.redirect to default2.aspx which in turn again redirects to default3.aspx page and then finally the httpmodule displays the following:

Now if you notice the HTTP Module displays /Default.aspx and not /default2.aspx or /default3.aspx.

What can be the reason behind it. If you notice the Request.FilePath associated with Httpmodule is still /Default.aspx and not any of /default2.aspx or /default3.aspx page. The reason being that in addition to being faster than redirection, server.transfer preserves all of the ASP built-in objects from the original request, including form values from an HTTP post. The moment we have server.transfer in our code the currently executing request will stop and will forward the request to the new page.

The new request also gets the original response stream further ahead for processing. Hence the property Request.CurrentExecutionFilePath will be same as the executing page when accessed in one of the above page class methods, but will be equal to the original request property if accessed in an HTTP Module. You can also consider it logically, why should there be a value for Request.CurrentExecutionFilePath in an HttpModule, it is called before or after the pages have been processed. So ideally it is not in context of any specific page. Hence it will show you the original page based on the assumption that the request was sent for the same page.

Getting little deeper: How ASP.Net Forms based authentication flows...

Saurabh Singh — Thu, 19 Apr 2007 13:42:00 GMT

I have been recently supporting Asp.Net apart from IIS in the role of a Microsoft GTSC Developer Support Engineer.

I had been a programmer earlier, but had more expertise on C, C++ and other unmanaged non-web stuffs. I am new to Web technology as per the programming background is concerned. I started working on specific topics which we regularly encounter in our daily support calls, and found Forms based authentication to be one of the most interesting and challenging topics to troubleshoot.

Here i take a moment to dig deep in explaining the forms authentication. The below analysis helped me in a big way to understand how the HTTP traffice flows and what are the headers we need to concentrate upon.

I will show a series of Web request/response flows when a user tries to access a website which is configured for Forms based authentication.

Let's say, a user requests for accessing a protected web page on a site.

So accordingly he should be redirected to a login page where he needs to enter the credentials and once validated against a user data store, he should be taken to the requested page.

For our example I have written a very generic code as shown below:

Default.aspx page, which checks whether user is authenticated or not. If yes, then it displays webpage content. If user is not authenticated he will be redirected to the login page. You can copy paste and try it for yourself.

Default.aspx

<%@Page Language="VB" %>
<%@Import Namespace="System.Web.Security" %>

Sub SignOut(objSender As Object, objArgs As EventArgs)
'delete the users auth cookie and sign out
FormsAuthentication.SignOut()
'redirect the user to their referring page
Response.Redirect(Request.UrlReferrer.ToString())
End Sub

Sub Page_Load()
'verify authentication
If User.Identity.IsAuthenticated Then
'display Credential information
displayCredentials.InnerHtml = "Current User : <b>" & User.Identity.Name & "</b>" & _
"<br><br>Authentication Used : <b>" & User.Identity.AuthenticationType & "</b>"
session("Name") = User.Identity.Name
Else
'Display Error Message
displayCredentials.InnerHtml = "Sorry, you have not been authenticated."
End If
End Sub

</script>

<html>
<head>
<title>Forms Authentication</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<span class="Header">Forms Based Authentication using standard method</span>
<br>
<br>
<div id="displayCredentials" runat="server" />
<br>
<br>
<form runat="server" method="POST">
<asp:TextBox id="TextBox1" runat="server" />
<asp:Button id="cmdSignOut" text="Sign Out" runat="server" onClick="SignOut" />
<asp:Button id="Button1" runat="server" text="Submit"/><br>
<asp:TextBox id="TextBox2" runat="server" />
</form>
</body>
</html>

<%@Page Language="VB" %>
<%@Import Namespace="System.Web.Security" %>

Sub ProcessLogin(objSender As Object, objArgs As EventArgs)

If FormsAuthentication.Authenticate(txtUser.Text, txtPassword.Text) Then
FormsAuthentication.RedirectFromLoginPage(txtUser.Text, chkPersistLogin.Checked)
Else
ErrorMessage.InnerHtml = "<b>Something went wrong...</b> please re-enter your credentials..."
End If

End Sub

</script>

<html>
<head>
<title>Standard Forms Authentication Login Form</title>
</head>

<body bgcolor="#FFFFFF" text="#000000">
<form runat="server">
<table width="400" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="80">Username : </td>
<td width="10"> </td>
<td><asp:TextBox Id="txtUser" width="150" runat="server"/></td>
</tr>
<tr>
<td>Password : </td>
<td width="10"> </td>
<td><asp:TextBox Id="txtPassword" width="150" TextMode="Password" runat="server"/></td>
</tr>
<tr>
<tr>
<td></td>
<td width="10"> </td>
<td><asp:CheckBox id="chkPersistLogin" runat="server" />Remember my credentials<br>
</td>
</tr>
<tr>
<td> </td>
<td width="10"> </td>
<td><asp:Button Id="cmdLogin" OnClick="ProcessLogin" Text="Login" runat="server" /></td>
</tr>
</table>
<br>
<br>
<div id="ErrorMessage" runat="server" />
</form>
</body>
</html>

For demonstration purpose I have added users to the web.config files instead of using any other store like a SQL server or Active Directory store for storing user's credentials.

Here is the web.config file section of our interest:

....
</credentials>
</forms>
</authentication>

</system.web>
</configuration>

Here if you notice, I have set the SlidingExpiration to False, which mean users will be logged out after a specific interval from the time they logged in, in our case it is set to timeout= "1" min.

If you want you can encrypt the user's credentials using hash algorithm like SHA1 etc. but it is not in the agenda of this blog.

I won't go much into the details about the settings here since you will get tonnes of articles on implementing forms based authentication on the net.

I will basically show you how Request/Response flow occurs between the server and the client during Forms based authentication.

Here we go:

Step 1: Client sends a web request for the Default.aspx (or any page of your choice in the website except the login page; who would prefer to go through a login page to access one's desired webpage if given a chance :-)) page to the server.

[You can focus only on the bold headers for our purpose]

You type in the following url in the IE browser, http://saurabsi-sec/FormsAuthentication/default.aspx and hit Go!

From Client

Step 2: Server sends a response back to the Client with a status 302 Object Moved:

From Server

HTTP/1.1 302 Found
Date: Thu, 19 Apr 2007 07:11:43 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftOfficeWebServer: 5.0_Pub
X-AspNet-Version: 2.0.50727
Location: /FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 196

Notice the Response status code and the Location in the response header. Server says to the client that it (client) needs to resend a request to the url mentioned in the Location header.

Step 3: Client then resends a new request for a /FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx
page. Now here since the client has to first get to the login.aspx page it will send a GET request first and not a POST request. Remember the first request to any site will be a GET and not POST.

From Client

GET /FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
Host: saurabsi-sec
Proxy-Connection: Keep-Alive

Remember the querystring ReturnUrl shows the original requested page. Client is supposed to send a request later after authentication is done to this page. This is the way how the request/response maintains a track of the requested page throughout the transaction.

Step 4: Server sends back the requested login.aspx page with a 200 OK Response.

From Server

HTTP/1.1 200 OK
Date: Thu, 19 Apr 2007 07:11:43 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftOfficeWebServer: 5.0_Pub
X-AspNet-Version: 2.0.50727
Set-Cookie: AppSessionCookie=vtd2qg55mkcypqnn53obxm45; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 1427

Notice that Session ID gets created at this stage by the server and is sent along with the response to the client. From now onwards Server will keep track of a user's session using this cookie. Note the session ID gets created at this stage and not the authentication cookie. Remember Session key gets created the moment a successful transaction occurs like a 200 OK between the server and the client.

Step 5: Now the client has recieved the login.aspx page. It enters the credentials for username and password and sends it across to the server again. Notice that this is a POST request to the login.aspx page now and this time it also sends credentials like username and password. We are sending the username and password as part of the Body of the request and not as part of the header.

From Client

POST /FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://saurabsi-sec/FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
Proxy-Connection: Keep-Alive
Content-Length: 277
Host: saurabsi-sec
Pragma: no-cache
Cookie: AppSessionCookie=vtd2qg55mkcypqnn53obxm45

You have the option of sending it as a querystring too, in such a case it will form a part of the request header and not body.

If you check the Queystring here, it shows ReturnUrl=/FormsAuthentication/default.aspx

Also checking the forms body, we find:

txtUser=john
txtPassword=test1
cmdLogin=Login

Step 6: Server receives the credentials and then goes ahead and authenticates the user. Once the user has been authenticated server responds back with a 302 Found response ,asking the client to send another request for the originally requested page, i.e. Default.aspx. How it determines the original requested page as default.aspx? You are right, it's through the querystring that we just discussed above.

From Server

HTTP/1.1 302 Found
Date: Thu, 19 Apr 2007 07:11:50 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftOfficeWebServer: 5.0_Pub
X-AspNet-Version: 2.0.50727
Location: /FormsAuthentication/default.aspx
Set-Cookie: FormsAuthCookie=82A747623272A0A3A0C36EC6AD1FBA35A47592B1CFB38E54A1A7C5BC24ECAA2563715D4225EAE8927B98EC3DAD6FB9875E67FCA344AECCA19837A40B2311E373; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 1590

Notice the FormsAuthCookie here, this has been set by the server once it authenticates the user. Server goes ahead and sends back this authentication cookie along with the response back to the client. Now next time the client sends back any request in the same session it should have the authentication cookie as well apart from the Session Cookie that was set earlier. Server will recognize the user and the ongoing session with the client based on the cookies sent to it in future requests.

Step 7: Now is the final round wherein Client after done with all the validation process etc, goes ahead and sends request for the Default.aspx page (remember it was also the very first request sent by the client in the whole process).

From client

GET /FormsAuthentication/default.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://saurabsi-sec/FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
Proxy-Connection: Keep-Alive
Host: saurabsi-sec
Pragma: no-cache
Cookie: AppSessionCookie=vtd2qg55mkcypqnn53obxm45; FormsAuthCookie=82A747623272A0A3A0C36EC6AD1FBA35A47592B1CFB38E54A1A7C5BC24ECAA2563715D4225EAE8927B98EC3DAD6FB9875E67FCA344AECCA19837A40B2311E373

Notice the cookies here. You will see there are two cookies being sent to the server separated by ";". One for the server to recognize the ongoing session with the client and the other one to recongize the authenticated user.

Step 8: Server has nothing else to do much but send back the response to the client for the requested web page.

From Server

HTTP/1.1 200 OK
Date: Thu, 19 Apr 2007 07:11:50 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftOfficeWebServer: 5.0_Pub
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 1111

You might notice something here, in the web.config file we had set the timeout value for Forms authentication cookie to be 1 minute, and session cookie to be 2 minutes. So, you might see a scenario wherein let's say a user gets logged out because of expired authentication cookie. In our example let's say a user gets logged out after 1 minute (authentication cookie timeout value being set to 1 minute), and he is redirected to login page. He logs in back this time after entering the credentials in the login page. But this time he uses a different credentials to login.

So what should happen, should the new user (with a different credentials this time) have access to all the original session variables (assuming session timeout has still not expired for the earlier user session) of the previous user when the same browser instance is running?

Answer is Yes, the new user with a different credentials this time will have access to all the session variables for the previous user, provided the same browser session is being used this time. Resaon being that the authentication cookie has expired but not the session cookie, so browser sends the vaild session cookies to the server and hence is able to access the session variables.

If we use a different browser session, of course a new session cookie has to be obtained which will invalidate session variables for the prevoius user.

Here I haven't gone into troubleshooting session loss issues, rather i have focused on how forms authentication process occurs between client and the server. In case your eyes are looking for some good logical reading on troubleshooting Session loss issues in ASP.Net, a must READ here http://aspalliance.com/1182_Troubleshooting_Session_Related_Issues_in_ASPNET