For this sample I've created a new IIS application within
the IIS 6.0 admin tool called "wildcardtest". It points to a
directory that will contain a few files: "default.aspx",
"login.aspx", "test.asp" and "test.htm" (these
last two files being resources not usually handled by ASP.NET):
Figure 1
By default when a URL request for a .aspx page
comes to the application, the ASP.NET ISAPI will process the request. By default
when a URL request for test.asp comes to the application, the classic ASP ISAPI
will process the request - and no ASP.NET code will run. When a URL
request for test.htm comes to the application, IIS6 will process the request
internally - and again no ASP.NET code will ever run.
We'll change this by enabling wildcard
mappings for this application, and configure ASP.NET to run code before and
after all requests to the server. To-do this, right-click on the
application within the IIS Admin Tool and select the "properties"
context menu item on it. This will bring up the application properties
dialog:
Figure 2
You can then click the
"configuration" button to pull up the URL mapping rules for the
application:
Figure 3
Note how the top of this dialog lists the
default ISAPI extension mappings (each URL extension is mapped to an ISAPI
responsible for processing it). The bottom half of the dialog lists the
"wildcard application map" rules. We can add a application
wildcard mapping to the ASP.NET ISAPI by clicking the "insert"
button, and pointing at the ASP.NET 2.0 ISAPI extension on disk:
Figure 4
Very, Very Important: Make sure that you
uncheck the "Verify this file exists" checkbox. If you don't do
this ASP.NET URL resources like WebResource.axd and other URL's handled by
ASP.NET that aren't backed by a physical file won't work anymore. This
will lead to errors within your pages.
Now close out all of the dialogs by clicking
"ok" to accept the changes. You've now configured ASP.NET to be
able to run code before and after each URL request into the application.
Enabling Forms Authentication and Url
Authorization for non-ASP.NET resources
Once we've completed the above steps to
register ASP.NET 2.0 as a wild-card mapping for all URLs into our IIS application,
we can then use the standard ASP.NET authentication and authorization
techniques to identify users in our application and grant/deny them access to
it.
For example, we could add a web.config file to
our application that enables ASP.NET's forms authentication feature for this
application, and sets up two URL Authorization rules that deny
"anonymous" users access to both the test.asp and test.htm URLs:
Listing 1
<span lang=EN><?xml version="1.0"?>
<configuration>
<system.web>
<authentication mode="Forms" />
</system.web>
<location path="test.asp">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="test.htm">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration> </span>
Now, when I attempt to access either "test.asp"
or "test.htm", the ASP.NET authentication and authorization system
will execute first to check whether I'm logged into the application with
forms-authentication, and if not redirect me to the login.aspx page within my
application for me to login:
Figure 5
Note how the "ReturnUrl" used by ASP.NET's forms
authentication system above has automatically set the "test.asp" url
to redirect back to once I'm logged in (this works just like it would for a
.aspx page). Once I successfully enter a username/password, I'll then
have access to the test.asp page:
Figure 6
Since the above page is a classic ASP file, I obviously
don't have a "User.Identity.Name" property that I can use to identify
the logged in user like I would in an ASP.NET page. However, I can
retrieve the "AUTH_USER" ServerVariable value within classic ASP to
obtain the username (ASP.NET automatically populates this before delegating the
processing back to the classic ASP ISAPI).
The code to use this from within classic ASP would look like
below:
Listing 2
<html>
<body>
<h1>Classic ASP Page</h1>
<h3>
You are logged in as:
<u>
<%=Request.ServerVariables("AUTH_USER") %>
</u>
</h3>
</body>
</html> Click here
to download a complete sample application that implements the above
solution. By default it will use a SQL Express database to store ASP.NET
2.0's Membership and Role Management data. Alternatively, you can create
and register a SQL 2000 or SQL 2005 database to store the membership and role
management values. This older ASP.NET Security tutorial I did shows how to-do
this.
