Last post Feb 14, 2009 12:54 PM by SimonRigby
Feb 14, 2009 11:11 AM|SimonRigby|LINK
I have a web application that I need to do some work on for a client. In essence this application allows users to view certain pages based on their logon details (its actually pages relating to courses they are enrolled on). Each of these pages contain links
to files on the web server (all in a directory called 'assets' although they are organised with subdirectories below that assets directory). The security is hand rolled and it works in terms of not letting a user browse to a page they don't have permission
to access, however the files are freely available by browsing to them. They are named using a particular naming strategy that makes it pretty easy to guess what other files might be, hence allowing students to gain access to these files for courses they are
not enrolled on.
My breif is to shield these asstes from public browsing, using the existing authentication mechanism (all of the data for determining whether students are enrolled on courses and the methods for authentication exist in a seperate class library). As there
are thousands of pages with embedded links to the files there is a caveat on this project that if a solution can be devised that doesn't involve moving the folders then it will be preferred as links will not need to be edited.
My intention is to firstly deny anonymous access to the assets directory and then write an HttpHandler to trap all requests to '/assets/*', authenticate the user and then either stream the file as a download or redirect the user to the login page (as per
the brief). I have done a proof of concept and it works as expected but I just wanted to run this past some other knowedgable souls to see if there any gotchas that I might be missing. It seems ideal to me but I am relatively inexperienced in the area of handlers
and as such wanted to see what the general concencus was. By all means please ask for any more detail that may be required.
Feb 14, 2009 12:15 PM|mbanavige|LINK
you havenet said what type of files your asset files are.
by default, IIS does not route non asp.net files through aspnet_isapi. So files like htm, pdf, doc, gif, jpg etc... are not protected by asp.net security mechanisms. You wont see this behaviour if you are testing locally using the VS built-in web server
as all files are routed through aspnet_isapi by the built-in browser.
Feb 14, 2009 12:38 PM|SimonRigby|LINK
Ah .. good point. So let me get this straight. If I was to have a link like ...
<a href='/assets/somefile.doc'>A File</a>
... because that is a request that isn't routed through aspnet_asapi the handler wouldn't have the opportunity to intercept the request. I'm assuming the only way around this with IIS6 would be to turn wildcard mapping on. In reality the files will probably
be PDF's and DOC's but I can't guarantee that. I might go back to the client and see if I can narrow a file type set down.
Alternatively, is there a better way of tackling this?
Thanks for the feedback
Feb 14, 2009 12:43 PM|mbanavige|LINK
correct. the request for a doc file would be handled by iis without routing it through asp.net. And some people have gone down the wildcard mapping path to solve that.
I use httphandlers to protect pdf assets and such, but i am storing these files outside of the websites folder. So they are not accessible via a url except through my htphandler
Feb 14, 2009 12:51 PM|XIII|LINK
perhaps you can make use of 2 handlers? One of the explicit download via a byte stream (Response.BinaryWrite()). In that you can check for your authenticated and authorized users. To protect the files physically you can take a look at this article:
Protecting files with ASP.NET.
Feb 14, 2009 12:54 PM|SimonRigby|LINK
Yes that's almost exactly my experience with handlers, I have used them on another job in exaclty the way you are describing (ie pointing directly to the handler with url parameters). I might have to do some more reading into wildcard mapping. I've heard
talk about performance issues, but then I've also heard talk of those issues being overstated. Maybe time to some benchmarking.
Thanks again for your input. Most useful.