We have a very simple ASP.NET web site that uses the built in Forms Authentication provider out of the box for users, roles and security. Our internal business customers have hundreds of PDF documents that should only be accessible for specific users or roles within the company. A majority of users that need access to these files are outside the company firewall and do not have VPN access. The site must be hosted on Windows Server 2003 using IIS 6.

Although this problem could be solved in many ways, I wanted to make the site as dynamic as possible since our web master would need to make constant changes to files, structure, etc and we did not want a programmer having to make changes to specific code or a DBA maintaining a database of files, paths, etc. We also wanted to avoid using a network file share to host the files or wrap the site using Plain Text authentication.

The issue is Forms Authentication provides no security on the request stack within IIS 6 as it does in IIS 7. Because we can’t extend this, our files would be wide open to any attacker or malicious employee looking to download the file by figuring out the link or by users who had bookmarked certain files and later after they had been removed from that role, being able to still access them.

The Solution

The solution seemed easy. Some content management systems allow you to store files in databases, or use URL re-writing to accomplish this task, but I wanted something simpler and easier to extend or duplicate in the future. We’re all pretty familiar with IHttpHandler and it seemed since that’s the way the prior, more complex solutions perform this feat more often than not, why not give it a shot for this:

Setup

In order for ASP.NET to recognize the request for the PDF file and wrap it with the configured authentication method, we have to tell IIS to use the same ASAPI engine that is uses for ASPX, ASMX, etc.

I opened the properties for the web site/virtual directory in IIS Manager, clicked on the Configuration… button located within the application settings section and the first tab contains my ISAPI extensions:

Then, I clicked the “Add…” button to add the new .pdf extension using the same ASP.NET ISAPI DLL, c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll for GET requests of .pdf:

I’m using the “Verify that file exists” because the file really will exists, it’s not in a database or remote location or anything fancy like that.

Once that’s done, you’ll notice if you have security set up on your site and in your web.config file around a PDF file, say for:

<location path=”MyFile.pdf”><web.config><authorization><deny users=”?” /></authorization></web.config></location>

And you are not authenticated; you will immediately be taken to the login screen. Once you log in however you will get a compilation error page. This is because the ASP.NET CLR is trying to compile/execute your PDF as an ASP.NET extension file and it cannot for obvious reasons, it doesn’t know how to handle your file.

IHttpHandler

Now that security is taken care of, I needed to let ASP.NET know what to do with a PDF file. To do this I needed to create a simple IHttpHandler:

public class PdfHandler : IHttpHandler
{
    public PdfHandler() { }
    public void ProcessRequest(HttpContext context)
    {
        string path = context.Request.PhysicalPath;
        string name = path.Split(‘\\’)[path.Split('\\').Length - 1];
        if (!string.IsNullOrEmpty(path) && path.ToLower().EndsWith(“.pdf”))
        {
            context.Response.ClearHeaders();
            context.Response.ClearContent();
            context.Response.Clear();

            context.Response.Charset = null;
            context.Response.ContentType = “application/pdf”;
            context.Response.AddHeader(“Content-Type”, “application/pdf”);
            context.Response.AppendHeader(“Content-Disposition”, string.Format(“inline;filename={0}”, name));
            context.Response.WriteFile(path);
        }
        else
            throw new FileNotFoundException(“The page requested is invalid”, path);
    }
    public bool IsReusable { get { return false; } }
}

This class, PdfHandler, implements the IHttpHandler interface which implements a proper, IsReuseable (which this one is not) and a method, ProcessRequest, which does the dirty work using the passed in HttpContext. In this case, I get the physcial path of the file being requested (remember that the file should always exist, otherwise IIS would have kicked the request back out) and then parse the name of the file, double check (using some sanity checking) that the file is indeed a PDF that we’re dealing with, clearing the response, setting the MIME type in the header and using the Response.WriteFile(filePath) method to output the file directly through the buffered response stream to the client. This would all be transparent to the user and the response time, although not as fast as IIS serving the file directly, is still acceptible for my means of use.

Web.Config Changes

Once I had the handler written for my PDF files, I just needed to let ASP.NET on the application level to use my handler for all PDF requests coming into the virtual directory/web site. I did this by using the configuration section under <web.config>, <httpHandlers>:

<httpHandlers>
    <add verb=“GET“ path=“*.pdf“ type=“PdfHandler“ validate=“false“/>
</httpHandlers>

With this entry in there now, everything is working great and now my web master and I can manage security in the application simply by adding folders and new web.config files with an <authorization/> section along with the built-in membership/role management that comes standard in ASP.NET application services.

Now if only I can get them on IIS 7, this entire article would become obsolete, but life would definitely be better!

Protecting PDF files in IIS 6 using Forms Authentication is a post from: Chad Scharf's Weblog. For software consulting services please visit Scharf Holdings, LLC

Administrator Mode

OK, so Visual Studio 2008 likes to run with elevated privileges in order to access web sites on the local IIS server. That’s not so bad aside from losing the ability to drag and drop items into the IDE from Explorer. Then, about 4 weeks into using Windows Vista and Visual Studio 2008, I hit an odd snag. About 3 weeks ago I went to open a solution containing a web project, only to get this all too familiar message:

To access local IIS Web sites, you must run Visual Studio in the context of an administrator account. By default, Windows runs applications in a limited-privilege user account even when you are logged on to the computer as an administrator. To run Visual Studio with administrative privileges, right-click the Visual Studio icon and then click ‘Run as administrator.

Turns out, I WAS running Visual Studio under Administrative mode; however it didn’t seem to be recognizing this fact. After cursing Bill a few times I closed Visual Studio, re-opened it from the actual executable itself running as administrator; same deal. I rebooting my computer only to find that it still did not work, and on top of that my sound card was not working, however device manager said that is was operational and no errors were reported in any of the Event logs.

Now, no web projects and no sound card, what’s next? I open up the IIS7 manager to check on my web settings when I find this:

The red “X” on the Default Web Site and a status of “Access Denied” for the web site in the web site list. I go to check my applications pools, and sure enough, the same thing:

The odd thing about all of this was that I could still access all of the sites in my Default Web Site, either using the “Browse” command from the IIS Manager or simply opening Internet Explorer and going to http://localhost/whatever. I attempted to run Windows Update which also gave me cryptic errors such as “WAS does not appear to be enabled”. This was about the time I opened a support ticket with Microsoft.

Tinker Not

Little did I realize as I told the IIS team support technician that there were no recent changes to my computer. There was however one significant detail that I didn’t think was significant at the time: I had rebooted my computer. Typically I simply lock my workstation for the night or for the weekend and perhaps reboot once every other month. Turns out the day before this all started happening I had rebooted my machine for the 3^rd time since installing Windows Vista, this was a mistake.

Turns out when you change DCOM security settings on your machine using dcomcnfg, and Windows Vista warns you that things may stop working, and you ignore these warning it’s really YOUR fault your machine sucks and not Microsoft’s. After all, I was warned when I inadvertently tried to fully open all DCOM and MSDTC permissions on my box which I was accustomed to doing COM development on previous versions of Windows. Two little drop down boxes that I had set were the cause for all of this grief, “DCOM Default Authentication Level” and “Default Impersonation Level“.

These were the settings I had chosen without guidance or really much thought:

Turns out these configuration changes are BAD! Do not do this unless you want a Vista pile of worthless garbage under your desk. Of course these changes didn’t start affecting services until I had rebooted, a couple of weeks after making this change which I had completely forgotten about.

Below is what I should have kept, and sure enough shortly after resetting these and rebooting not only did IIS 7 begin working again as expected, Visual Studio, my sound card, Windows Update, my CD Burner as well as my sanity were back in check as well.

It was all thanks to this post that I found on an MSDN forum while trying to troubleshoot my sound card that lead to start looking at COM permissions. I followed all the steps in this post and many more similar ones to no avail, until I vaguely remember screwing around with the DCOM security configuration and more importantly the nice warning message this had given me when I changes those settings. Sure enough after changing them back I’m back in business and promise to never ignore Bill again.

Thanks Bill

So you can say what you want about Microsoft and Windows Vista, but I love it and can’t wait for some of the new and emerging stuff that’s soon to come. After all, had I been using Linux or a Mac, the OS would have let me be stupid without a warning and I would have never been the wiser. So for those developers and techies that like to tinker, the best of luck to ya, I’m sticking to Windows defaults from here on out, they’re really not that bad anyway.

You can’t always blame Bill when Vista breaks is a post from: Chad Scharf's Weblog. For software consulting services please visit Scharf Holdings, LLC