ASP.NET handles requests for file extensions that are normally associated with ASP.NET, while IIS handles requests for all other file extensions. By default this
means common file extensions such as .aspx and .asmx are processed by ASP.NET. This processing includes authentication and authorization to ASP.NET files. Sometimes
though, a developer wants non-ASP.NET resources to be processed by ASP.NET. One reason for processing non-ASP.NET files through ASP.NET is to allow ASP.NET
authentication and authorization to control access to these types of files.
The combination of IIS6 on Windows Server 2003 and ASP.NET 2.0 provides the most flexibility for running the ASP.NET pipeline as part of processing a request for a
non-ASP.NET resource. IIS6 includes support that allows ASP.NET 2.0 to perform authentication and authorization steps, and to then hand off the remainder of the
processing of a non-ASP.NET resource back to IIS6. For example, it is possible to authenticate access to an ASP page using ASP.NET forms authentication, authorize access
with ASP.NET's Url authorization and still allow the ASP ISAPI extension (asp.dll) to execute the ASP page. This support is possible because IIS6 introduced a new server
support function for ISAPI extensions: HSE_REQ_EXEC_URL.
Assume that a directory structure contains a mix of both ASP and ASP.NET files. The ASP.NET pages are used to log a user in with forms authentication, while the
ASP pages represent the rest of the application. Using the IIS6 MMC, right-click on directory and create an application (this is the same step that is necessary
when setting up a standard ASP.NET application). After an application has been created, click on the Configuration button that is located on the Directory
property page. This will cause the Application Configuration dialog to be displayed. New to IIS6 is a feature called wildcard application mapping. The
bottom of the Application Configuration dialog allows you to configure this feature.
First determine the path for the ASP.NET ISAPI extension that processes ASP.NET files such as .aspx files. You can find this path by looking at the
extensions that are listed in the Application Extensions list shown in the top half of the Application Configuration dialog. Click on the row in the list
that maps the .aspx extension, and select the Edit button. In the dialog that pops up, highlight the text in the Executable textbox and copy it to the clipboard. Then cancel out
of the dialog.
Next, click the Insert button that is in the bottom half of the Application Configuration dialog. A dialog box titled Add/Edit Application Extension
Mapping will be displayed. In the Executable text box, enter the path to the ASP.NET ISAPI extension that you copied to the clipboard earlier. The end result
should look something like the screenshot below.
mgraber on 15 Nov 11"Encrypting View State Although MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data. You can prevent people from viewing this data in two ways: by transmitting the page over SSL, and by encrypting the view state data. Requiring the page to be sent over SSL can help prevent data-packet sniffing and unauthorized data access by people who are not the intended recipients of the page. However, the user who requested the page can still view the view state data because SSL decrypts the page to display it in the browser. This is fine if you are not concerned about authorized users having access to view state data. However, in some cases, controls might use view state to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain sensitive data, such as customer IDs, you should encrypt the view state data in addition to or instead of sending the page over SSL. To encrypt the data, set the page's ViewStateEncryptionMode property to true. If you store information in view state, you can use regular read and write techniques; the page handles all encryption and decryption for you. Encrypting view state data can affect the performance of your application. Therefore, do not use encryption unless you need it. Control State Encryption Controls that use control state can require that view state be encrypted by calling the RegisterRequiresViewStateEncryption method. If any control in the page requires that view state be encrypted, all view state in the page will be encrypted. Per-user View State Encoding If a Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a pre
