Protect Your Downloadable Files Using HTTP Handlers

So you finally have a product to sell, and a site to sell it on. But wait; how do you prevent unauthorized users from downloading your products? Forms Authentication provides only part of the solution. In this article, I’ll show how to prevent specific users from accessing specific files on your site; even by browsing directly to them.

This article attacks a problem for which I have heard many solutions: How can I offer file downloads on the Internet and protect them from unauthorized downloading? There are many answers to this problem, but some are not without their own problems. In this article, I’ll review some of the techniques commonly used by software vendors, and then show you my solution for this. I should tell you that my solution is not a Miguel Castro original; it is, in fact, used by many ASP.NET sites-don’t ask me how the Java guys do it.

Common File Protection Techniques

Many of us purchase software on the Internet all the time-a little too much, my wife tells me, but that’s another story. You’ve most likely experienced some of the common protection scenarios for file downloads. I’ll review them below.

Zip-file Password Protection

Simple in its approach, you don’t protect the file from being downloaded; instead you protect an unauthorized person from extracting the file’s contents. WinZip and many other compressors out there offer a password protection feature. However, as you can already imagine, once you give out that password to someone whom you consider authorized to access the file contents, there’s nothing stopping that person from giving that password to someone else. And you know how the Internet is; the password always gets around. The only thing you can really count on is the ethics of the person to whom you give the file and password, and hope that they don’t hand it out. You can take this kind of protection to a higher level by generating a zip on-the-fly for a specific person, and then sending them the file. You would, of course, need a file-storage solution that is inaccessible through the Web browser, since you need to have control over what files get sent to what user. This leads me to the second method of file protection.

E-mails

Many software vendors don’t post files for download on their Web sites. Instead, they send an e-mail to users who have purchased the product with the download details and sometimes even with the file itself. The e-mail can contain a link to download the file and indicate that it will only be accessible for a certain period time. Sometimes a software vendor might combine this technique with password protection. Any other protection required once the file is in the hands of the user is a topic for another article-licensing and registration. Other e-mail-based solutions also include dynamically generating file names.

Temporary File Names

To throw confusion and complication into the mix, some vendors dynamically generate a file name using a GUID or some other cryptic naming technique. They also tend to make the file available for download only for a limited time.

Reviewing the Techniques

While these techniques do work up to a point, a good programmer could crack them. But more importantly, none of these techniques offer you the ability to host a “client” area on your Web site where a user can look at their purchase history and re-download their software any time they wish. In my opinion, a site that offers this kind of features offers the best user experience and also the best manageability for you, the software provider. After the user has purchased the product, you can simply send the user an e-mail with their license key and a link to their “client” area on your site. Knowing that they can log in and download their software any time they want gives a user peace of mind, in case they ever lose their product files.

I’m going to show you how to provide just that very kind of user experience using ASP.NET Forms Authentication in conjunction with something called HTTP handlers.

HTTP Handlers

I’ve read many articles that discuss custom HTTP handlers in ASP.NET, and I’ve found many of them a bit complicated. I don’t think this topic is that difficult to comprehend.

I can offer many examples for when you could use HTTP handlers, but in this article I will concentrate on them in the context of solving the file protection problem.

I’ll explain what a handler is and how they work, and I’ll keep the explanation as simple as possible. HTTP handlers are classes that handle requests passed to them by IIS. When you install ASP.NET on a machine, the installation process adds a bunch of entries to IIS (Figure 1). These entries include all the extensions for files that you expect ASP.NET to take care of (ASPX, ASMX, etc.). When you request an ASPX page, IIS takes that and passes it to the appropriate DLL for handling; in this case aspnet_isapi.dll, which then instantiates the appropriate HTTP handler that continues processing the request. In the case of ASPX pages, the HTTP handler that gets invoked is the Page class that resides in the System.Web.UI namespace. For a more detailed description and walkthrough of the details of what goes on behind the scenes in ASP.NET, I encourage you to read Rick Strahl’s excellent article entitled “A Low-Level Look at ASP.NET Architecture” in the Nov/Dec 2005 issue of CoDe Magazine.

In the case of an ASPX page, the Page handler builds the controls and fires the life cycle events; essentially everything that you normally take for granted when you browse to an ASPX page.

However, you can write a custom HTTP handler that intercepts any request made from the browser in an effort to adjust or customize the behavior that would normally take place. There are a couple of techniques for doing this, which I’ll teach you in this article, but first I want to talk about those IIS entries and something you may already be familiar with-Forms Authentication.

By: Miguel Castro

Miguel is an architect with IDesign who specializes in architecture consulting and building .NET solutions. He is a Microsoft MVP and INETA speaker and has been a software developer for over 22 years. With a Microsoft background that goes all the way back to VB 1.0 (and QuickBasic in fact), Miguel jumped on .NET as soon as the first public Beta was released and has provided .NET solutions for clients around the country in a variety of industries. He considers himself to be a .NET Developer and Architect and has equal love for both VB and C#, and no tolerance for language bigotry. He’s spoken at numerous user groups around the country as well as developer conferences.

He’s the author of the CodeBreeze code-generator, which among things can be found on his Web site:

www.steelbluesolutions.com

Miguel currently lives in Lincoln Park, NJ with his wife Elena and his daughter Victoria.

subscriptions@infotekcg.com