Most of the time when we start learning something or doing something we get the
first question that how does it helps? Or where I can use in the real world?
Same thing goes in this technique as well. What are URL rewriting first of all
then what is routing engine? Let us see some real issues in our code.
A. Case 1
One day you had a URL book marked as Http://abc.com/main/1.aspx. But now it is
moved to Http://xyz.com/main/1.aspx, will it work now, no. But as a web site
developer or architect how you will manages these kinds of broken links in web
sites.
B. Case 2
Suppose we have two servers where each server has hosted with 50 pages. But
all the links have to be made available for both web sites. How do we handle
this situation?
C. Case 3
A website restructuring caused all of the Web pages in the /Admin/ directory to
be moved to a /finance/Admin/ directory, you would want to use URL rewriting to
check if a Web request was intended for a file in the /Admin/ directory. The
request automatically should redirect the request to the same file, but in the
/finance/Admin/ directory instead.
And there are many more, so how do we handle all these scenarios. In classic ASP
ages, it was very difficult to handle these scenarios, where we suppose to play
with the ISAPI filters. Off course some third party software's. In ASP.NET Http
Modules to handle all these using URL Rewriting as an another option.
I. ASP.NET URL Rewriting
By using URL rewriting, we can intercept an incoming Web request and redirecting
the request to a different resource page. When performing URL rewriting,
typically the URL being requested is checked and, based on its value, the
request is redirected to a different URL.
Please refer to my last post for what happens when request comes to IIS or Scott
Mitchell blogs or books from Dino Esposito you will really love them. And it is
must to understand this post.
II. Implementing URL Rewriting
In olden days URL rewriting was implemented with ISAPI filters at the IIS Web
server level or some third party software's, which we are not going talk here.
Our main focus is how to implement in ASP.NET. So, in ASP.NET URL rewriting can
be implemented by using HTTP modules at the ASP.NET level.
Using Http Modules by utilize the HttpContext object RewritePath () method. Here
I am not going to explain the HttpApplication or HttpContext assuming that you
have read my last post. But can tell one thing that; HttpContext class contains information about a specific HTTP request that is
received by the IIS. An HttpContext instance is created for that request. This
object contains properties to access the intrinsic object like Request, Response
which in turn access to Application, Session and User objects.
III. URL Rewriting with Built in HTTP Modules
We can use out of the box Http Modules to perform the URL rewriting. Let us
understand what are they and which event they are tied to in IHttpHandler. Let
us see some of the out of the modules that we use day to day, yes we are working
with the models, don't say that I never worked on Http Modules.
1. FormsAuthenticationModule
This module sets the identity of the user (to an IPrincipal) in the HttpContext
for an ASP.NET application when forms authentication is enabled.
FormsAuthenticationModule exposes AuthenticateRequest event. Where we can check
the user is authenticated or not. If not redirect to a login page. Usually what
we do use is Response.Redirect() but Context.RewritePath() method is also good
option
void FormsAuthentication_OnAuthenticate(object
sender, FormsAuthenticationEventArgs args)
{
if (FormsAuthentication.Authenticate("a",
"a") != true)
{
Context.RewritePath("WebForm2.aspx");
}
}
So how we implement in HttpModule is
namespace
Chinna.SampleModules
{
public class
SampleModule :
IHttpModule
{
public void
Dispose()
{ }
public void
Init(HttpApplication context)
{
context.AuthorizeRequest += new
EventHandler(OnAuthorizeRequest);
}
void OnAuthenticate(object
sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
app.Context.RewritePath("WebForm1.aspx");
}
}
}
2. FileAuthorizationMoudle
When using Windows authentication, This HTTP module checks to ensure that the
user account has adequate rights for the resource requested, and provides
authorization services against file-system access-control lists (ACLs). Check
the following code
IntPtr userToken = System.Security.Principal.WindowsIdentity.GetCurrent().Token;
if (FileAuthorizationModule.CheckFileAccessForUser("~/WebForm1.aspx",
userToken, "GET") ==
true)
Response.Write("You have access !!");
else
Context.RewritePath("WebForm2.aspx");
So how we implement in HttpModule is
namespace
Chinna.SampleModules
{
public
class SampleModule
: IHttpModule
{
public
void Dispose()
{}
public
void Init(HttpApplication
context)
{
context.AuthorizeRequest += new
EventHandler(OnAuthorizeRequest); }
void
OnAuthorizeRequest(object sender,
EventArgs e)
{
HttpApplication app
= (HttpApplication)sender;
app.Context.RewritePath("WebForm1.aspx");
}
}
}
3. UrlAuthorizationModule
The UrlAuthorizationModule determines whether the current user is permitted
access to the requested URL. You can allow or deny a user or a role using allow
or deny subelements in Authorization config element in the web.config,
respectively.
Allow and deny subelements are interpreted in the order they appear in the
configuration. Once an element specifies that access is allowed or denied, the
UrlAuthorizationModule completes its authorization check. For example, the
following authorization section from a Web.config file requires users to log on
(by denying anonymous users), and then allows only users in the Administrators
role to have access. Users not in the Administrators role are denied.
For example: The following code example grants access to Chinna and members of
the Admins role, while denying it to Rick and all anonymous users.
<authorization>
<allow
users="Chinna"/>
<allow
roles="Admins"/>
<deny
users="Rick"/>
<deny
users="?"/>
</authorization>
IV. URL Rewriting with Custom HTTP Modules
We can implement the custom URL rewriting by implementing custom Http Module.
You can refer to my last post for the same. Or see the below sample code.
public class
SampleModule :
IHttpModule
{
public void
Dispose()
{ }
public void
Init(HttpApplication context)
{
context.BeginRequest += new
EventHandler(OnBeginRequest);
context.EndRequest += new
EventHandler(OnEndRequest);
}
void OnBeginRequest(object
sender, EventArgs e)
{
HttpApplication appObject = (HttpApplication)sender;
HttpContext contextObject =
appObject.Context;
contextObject.RewritePath("~/WebForm1.aspx");
}
}
I would also like to tell you one more thing that, the BeginRequest event fires
before AuthenticateRequest, which fires before AuthorizeRequest. Because of this
reason it is also best place to use the URL rewriting. As I said earlier it is
not mandatory to write the custom http modules and register them in web.config.
You might have noticed in my last post that we are ultimately using
HttpApplication class and its events. So we have also one location which uses
HttpApplication class, which is Global.asax page which is default
HttpApplication class for ASP.NET project.
Go to your project Global.aspx.cs and add the following code, also remember
whatever code you can write in custom module, you can also write in
Global.asax.cs file
void FormsAuthentication_OnAuthenticate(object
sender, FormsAuthenticationEventArgs args)
{
if (FormsAuthentication.Authenticate("a",
"a") != true)
{
Context.RewritePath("WebForm2.aspx");
}
}
Hope this helps.