Israel Aéce

I'm working at ASP.NET Web Application project and I created a handler, that obviously implement an IHttpHandler Interface, for process and generate a binary file to force a download it.

After config the Web.Config file, the request for "*.abc" file extension will be now intercepted for this handler. But, there is a big problem here, because I'm using the Server.Transfer method, so I cannot send a handler instance for overload of this method or call the "virtual path" directly, like "Page.abc". You can confirm this information decompiling the Transfer method using the Reflector tool:

[ --- Supress --- ]
else if (!(handler is Page))
{
   error = new HttpException(0x194, string.Empty);
}
[ --- Supress --- ]
if (error != null)
{
   [ --- Supress --- ]
   throw new HttpException(SR.GetString("Error_executing_child_request_for_handler",
      new object[] { handler.GetType().ToString() }), error);
}

Independently of Transfer method overload that you use, the error message is the same: "Error executing child request for [handler | Page.abc].". So, the reason why I cannot use the Response.Redirect is that I need to send parameters through Context.Items collection for security intentions.

The temporary solution is to inherit the Page class instead implements IHttpHandler Interface in my handler, but I believe that "solution" isn't elegant.

After read the last Alexandre Tarifa's post, I remembered a software that a student show me in the last class.

The software is MM.NET (Mere Mortals .NET). Beyond a nice name, this software seems magic. There are many cool features (like VS.NET Windows and Web Templates, mappers, etc) and some others details that differ among others.

This is a video about use of the MM.NET.

I'm finishing the Luis Abreu's ASP.NET 2.0 book, and he speaks about de Control State feature. This is a very cool feature, because the server side controls don't save the important information about your functioning in ViewState.

In 1.x ASP.NET versions, this information is stored in ViewState, so when the ViewState is disable, some controls doesn't work correctly. For example, disable the View State and try to change the index pagination of the DataGrid control. You’ll see that the control will disappear.

With the ControlState, this important information is stored in other place and if you disable the ViewState, the control will continue to working normally. To disable the ViewState is very important when you don't preserve the control state during the postbacks or when the performance of your application is low.

In 1.x version of the ASP.NET, there is a problem when we request the files non-ASP.NET that are "protected" by Forms Authentication. The problem is that resources not pass by ASP.NET authentication and authorization modules, so independent of Web.Config's settings, the protected resource always will be visible for all users, also anonymous users.

The solution for this is to map the protected file (extension) using the HttpForbiddenHandler handler in Web.Config file of the application or configuring the IIS directly, like I show on this post. But these solutions are very complicated, because in the first case the ASP.NET runtime will serve all requests, so the performance degrades. The second solution maybe is impossible because the hosting service doesn't allow to configuring them server.

The ASP.NET 2.0 solved this problem adding a new handler called DefaultHttpHandler (for verbs: GET, HEAD and POST). This handler is performed for all non-ASP.NET files (like images, *.htm, *.asp, etc.), making the user validation and checking if he has permission. If it's valid, the IIS will return request for the responsible by process of this resource. Now, the performance is very good and you can use the Forms Authentication infraestructure (authentication and authorization modules) to protect your non-ASP.NET files.

When we work with restrict access in determined pages/sections of the ASP.NET Web Application, we must worry with the use of the Transfer method, localized in HttpServerUtility class.

Imagine that the users with minimum privileges haven’t permissions for a page because  they don´t belong in Administrators role. Put a button in page that all users have access and via Transfer method; it will call the restrict page. Run the application and click in button. You'll see that the user will access the page independently if he have or not access for it.

This happens because the authentication and authorization process isn't executed when the Transfer method is called. The process already happened when the user requested the resource (page) in browser.

There are two ways to resolve this problem: one is call the Redirect method instead  of Transfer. This will force a client/browser request, so the authentication and authorization process re-run. A second way is to continue using the Transfer method and in the destination page to validate the user through IsInRole method and check if he have permissions for access the resource.