URL rewriting in ASP. NET (3)

Using the RewritePath () method of the System. Web. HttpContext class, URL rewriting can be implemented at the ASP. NET level. The HttpContext class contains HTTP-specific information about a specific HTTP request. For each request received by the ASP. NET engine, an HttpContext instance is created for this request. This class has the following attributes: Request and Response, which provide access to incoming requests and outgoing responses; Application and Session, which provide access to applications and Session variables; User, provides information about users who have passed identity authentication and other related attributes.

Use the Microsoft & reg;. NET Framework Version 1.0 and RewritePath () Methods to accept a single string as the new path to use. The RewritePath (string) method of the HttpContext class updates the Path and QueryString attributes of the Request object internally. In addition to RewritePath (string),. NET Framework 1.1 also includes another form of RewritePath (). This method can accept three string input parameters. This alternate form of overload requires not only setting the Path and QueryString attributes of the Request object, but also setting internal member variables, which are used to calculate the PhysicalPath, PathInfo, and FilePath attribute values of the Request object.

To implement URL rewriting in ASP. NET, you need to create an HTTP module or HTTP processing program to complete the following operations:

1.
Check the requested path to determine whether the URL needs to be rewritten.

2.
To override the path, call the RewritePath () method to override the path.

For example, suppose our website contains every employee via/info/employee. aspx? Information that can be accessed by empID = employeeID. To enable the URL to be more segmented, we can decide to visit the employee page through the following address:/people/EmployeeName. aspx. This is an example of using URL rewriting. That is to say, when requesting the/people/ScottMitchell. aspx page, we need to rewrite this URL to use/info/employee. aspx? EmpID = 1001 page.

Use the HTTP module to perform URL rewriting
You can use the HTTP module or HTTP processing program to perform URL rewriting at the ASP. NET level. When using the HTTP module, you must determine the time point during the request validity period to check whether the URL needs to be rewritten. At first glance, this seems to be an option, but the decision will impact the application in an obvious and subtle way. Because the built-in ASP. net http module uses the properties of the Request object to execute tasks, it is very important to choose where to execute rewrite. (As described above, the rewrite path will change the attribute value of the Request object .) These closely related built-in HTTP modules and their bundled events are listed below:

HTTP module Event Description
FormsAuthenticationModule
AuthenticateRequest
Determine whether the user has passed form authentication. If not, the user is automatically redirected to the specified logon page.

FileAuthorizationMoudle
AuthorizeRequest
When using Windows authentication, this HTTP Module checks to ensure that the Microsoft & reg; Windows & reg; account has sufficient permissions for the requested resources.

UrlAuthorizationModule
AuthorizeRequest
Check to ensure that the requester can access the specified URL. Use the <authorization> and <location> elements in the Web. config file to specify URL authorization.

As mentioned above, the BeginRequest event is triggered before AuthenticateRequest, and the latter is triggered before AuthenticateRequest.

A safe location for URL rewriting is in the BeginRequest event. That is to say, if the URL needs to be rewritten, this operation will be executed after any built-in HTTP module is run. This method has some defects when using form authentication. If you have used form authentication before, you will understand that when users access restricted resources, they will be automatically redirected to the specified Login Page. After successful logon, the user will be returned to the page on which they first attempted to access.

If URL rewriting is performed in the BeginRequest or AuthenticateRequest event, the logon page (after submission) redirects the user to the rewritten page. That is to say, if you type/people/ScottMitchell. aspx in the browser window, this address will be rewritten to/info/employee. aspx? EmpID = 1001. If you configure a Web application to use form authentication, when the user first accesses/people/ScottMitchell. aspx, the URL will first be rewritten to/info/employee. aspx? EmpID = 1001; next, FormsAuthenticationModule runs and redirects the user to the logon page (if needed ). However, after successful logon, the user will be sent to/info/employee. aspx? EmpID = 1001, because after FormsAuthenticationModule runs, this URL is the requested URL.

Similarly, when rewriting is performed in the BeginRequest or AuthenticateRequest event, UrlAuthorizationModule will see the rewritten URL. That is to say, if you use the <location> element in the Web. config file to specify authorization for a specific URL, you must reference the rewritten URL.

To solve these minor problems, you can decide to execute URL rewriting in the AuthorizeRequest event. This method solves some problems of URL Authorization and form authentication, but also creates a new problem: file authorization cannot work. When Windows authentication is used, FileAuthorizationModule checks to ensure that authenticated users have access to specific ASP. NET pages.

Assume that a group of users do not have Windows-level file access permissions for C: \ Inetput \ wwwroot \ info \ employee. aspx, and attempt to access/info/employee. aspx? EmpID = 1001, they will receive an authorization error message. However, if we move the URL rewriting to the AuthenticateRequest event, when the FileAuthorizationModule checks the security settings, the requested file is still considered as people/ScottMitchell. aspx because the URL must be overwritten. Therefore, the file authorization check will pass, allowing this user to view the rewritten URL/info/employee. aspx? EmpID = 1001 content.

Then, when should I rewrite the URL in the HTTP module? This depends on the authentication type to be used. If you do not want to use any authentication, it does not matter whether URL rewriting occurs in BeginRequest, AuthenticateRequest or AuthorizeRequest. If you want to use form authentication instead of Windows authentication, rewrite the URL and run it in the AuthorizeRequest event handler. Finally, if you want to use Windows authentication, arrange URL rewriting during the BeginRequest or AuthenticateRequest event.

Execute URL rewriting in the HTTP processing program
The URL can also be rewritten by the HTTP handler or the HTTP handler factory. As mentioned above, an HTTP handler is the class responsible for generating the content of a specific type of request; an HTTP handler factory is the class responsible for returning an HTTP handler instance, which can generate content of a specific type of request.

In this article, we will discuss how to create a URL rewrite HTTP handler factory for ASP. NET web pages. The HTTP handler factory must implement the IHttpHandlerFactory interface, which includes the GetHandler () method. After the corresponding HTTP module is initialized, the ASP. NET engine determines which HTTP handler or HTTP handler factory is called for the given request. If you want to call the HTTP processing factory, the ASP. NET engine will pass in the GetHandler () method of the HTTP processing factory of HttpContext for the Web request call and some other information. Then, the HTTP handler factory must return an object that implements IHttpHandler that can process requests.

To execute URL rewriting through an HTTP program, we can create an HTTP processing program factory. The GetHandler () method of the processing program factory will check the requested path, to determine whether to rewrite the URL. If needed, it can call the RewritePath () method of the incoming HttpContext object, as discussed earlier. Finally, the HTTP handler factory can return the HTTP handler returned by the GetCompiledPageInstance () method of the System. Web. UI. PageParser class. (This technology is the same as the technology used when the built-in ASP. NET webpage HTTP handler factory PageHandlerFactory works .)

Since all HTTP modules will be initialized before the custom HTTP handler factory is instantiated, When you overwrite the URL in the second half of the event, using the HTTP handler factory brings the same risk, that is, file authorization cannot work. Therefore, if you rely on Windows Authentication and file authorization, you may want to rewrite the URL using the HTTP module method.

In the next section, we will discuss how to build a reusable URL rewriting engine. After introducing the URL rewriting engine (which can be obtained by downloading the code in this article), we will introduce the actual usage of URL rewriting in the remaining two sections. First, we will discuss how to use the URL rewriting engine and introduce a simple URL rewriting example. Next, we will use the RegEx function of the rewrite engine to provide a truly "strikethrough" URL.

Back to Top
Build a URL rewriting Engine
To help describe how to implement URL rewriting in ASP. NET Web applications, I have created a URL rewriting engine. This rewrite engine provides the following features:

• The ASP. NET page developer who uses the URL rewriting engine can specify the rewrite rules in the Web. config file.

• Rewrite rules can use regular expressions to implement powerful rewrite rules.

• You can easily rewrite the URL to use the HTTP module or HTTP handler.