o 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 you how to prevent specific users from accessing specific files on your site; even by browsing directly to them.
There are many answers to this problem, but some carry their own problems. In this article, I'll review some of the techniques commonly used by software vendors, and then show you my solution. I should tell you that my solution is not a Miguel Castro original; it is, in fact, used by many ASP.NET sitesdon't ask me how the Java guys do it.
Common File Protection Techniques
|When you request an ASPX page, IIS passes the request to the appropriate DLL for handling|
Many of us purchase software on the Internet all the timea 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.
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 articlelicensing 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 users can look at their purchase history and re-download their software any time they wish. In my opinion, a site that offers these kinds of features offers the best user experience and also the best manageability for you, the software provider. After users have purchased the product, you can simply send them an e-mail containing 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 users 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.
The System.Web.UI.Page class is itself an HTTP handler and is registered in the root Web.config file on your machine.
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 (see 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 "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 withForms Authentication.