• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1458
  • Last Modified:

authentication doesnt deny access to non aspx (htm, pdf, img, etc) files


When you specify authentication in a web.config using (as a simple example):

<authentication mode="Forms">
   <forms name="AuthCookie" path="/" loginUrl="login.aspx" protection="All" timeout="30">
      <credentials passwordFormat="Clear">
        <user name="userA" password="aPassword" />
   <deny users="?" />

and then navigate to an aspx then you get redirected to the login.aspx

However, when you navigate to a non-aspx page, such as test.htm, test.pdf, test.gif or test.asp you are allowed access.

I previously worked on a project based on ASP (classic) that used Siteserver membership authentication, also via forms login.  This works fine and would intercept ANY request and redirect to login if authentication failed.

I have read that a work around is to alter the IIS configuation so that the files (.gif, .pdf, etc) are processed by the aspnet_isapi.dll, but this seems far from ideal
it would also not work for any file that required processing by a different dll (ie .asp files, for which we will have some, which need to be processed by asp.dll)

Is there something that I am missing?
Is it fixed in asp.net 2.0 (am using 1.1)?
if not, any alternatives people have found as this is a bit useless and worse off than back in the grey old days of NT / IIS4 / SiteServer!!

  • 6
  • 4
  • 2
1 Solution
That's how it works.
asp.net is a http extension to IIS, so unregistered files types will not be passed to asp.net
for processing.
And you can alter the IIS configuration to register file types application by application.
So your configuration in one application will not effect other applications.
>> Is there something that I am missing?
You are not missing anything. Essentialy, requests to html pages, images or static contents is handled natively by IIS. And other requests to .aspx, .ascx, .asp, etc can be routed to ISAPI extensions, like asp.dll or aspnet_isapi.dll. You can customize IIS to specify what extensions are mapped to what ISAPI extensions. Since only ASP.NET related files are handed off to ASP.NET worker process, you won't see FormsAuthentication has any effect to html pages, images or static contents.

>> Is it fixed in asp.net 2.0 (am using 1.1)?
I haven't read all the new stuff in asp.net 2.0. But as for this "fixed", I don't think so. Because this is not a bug or anything wrong. And you still have the flexibilities to change this default behaviour to meet your requirement.

These articles describe on what needs to be done to protect other than ASP.NET related file types
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

stevenbakerAuthor Commented:
Thanks for the responses.

Understand the concepts, just thought that wanting to restrict access to ANYTHING in a restricted folder was a pretty basic requirement for authorisation and was the way it worked in asp with site server, even though non asp files were not handled by the asp.dll.  The slight concern I have with mapping everything to the asp.net api is that it will add extra load to requests, but guess as long as carefull about placing ONBLY sensitive info into restricted folders that would be fine (ie not placing spacer images in there!)

Still leaves a problem for the current project I am on.
It will have a 2-stage conversion from asp -> asp.net, so in phase 1 will still have some ASP pages but running on IIS6 that need to be restricted.
Obviously we cant change the asp pages to be handled by the .net isapi, so anyone got any ideas as to how to restrict access to these pages?

Thoughts that we had were: (none of which have been tried out...)

- have a redirector page (ie getAspPage.aspx?file=aspPageUrl) that would authenticate and if succesfull do a server.redirect to the asp page?
- have an asp include that is dropped into all asp pages that should be restricted that calls a .net class via COM to check if we are authenticated, doing a response.redirect if not
- users will be authenticated via AD, so login process could perhaps use the user as the identity in which the aps worker process is run under.  we could then add users to the appropriate groups (IIS_WPG) and only allow access to restricted folders using NTFS - although not sure how this would be done (know can use application pools and impersonate users that way, but not sure how you would do this as part of the login process - would also need to make authorization denied page go to our login page)

oh, and NO chance of migrating all the asp files across to .net, that's phase 2....

any comments or ideas appreciated....
You can implement what asp.net does.

For each page, you will check if an authentication cookie is set, if not, redirect to login page.
In login page, if the user input correct username and password, an authentication cookie is sent to client.

Or you can use a session variable instead of the cookie.
stevenbakerAuthor Commented:
Sessions out of the question for web apps and against our general development guidelines.

Will look a bit further into mimicking the .NET authentication tests though, although would think there was a bit more to it than checking whether formsAuth=true (or equivalent) as that would be a wee bit easy to mimick (ie javascript:document.cookies...... etc)?
>> Understand the concepts...
You have missed out something very cool in the concept :o) But it isn't in any article I posted above.
After modify the default ISAPI extension mapping in IIS, all requests for some file extensions will be handed of to ASP.NET worker process. Then each file type is handled by a http handler, for example, requests to .config files is handled by System.Web.HttpForbiddenHandler. That means, if you try to open web.config via your browser you'll see "This type of page is not served." server error message. Similarly, if you alter .asp file extension to be handled by aspnet_isapi.dll; you'll see the same error message if you try to open a .asp file. Got the idea?
Basically what you need to do is to intercept http requests made to your website in order to reject or accept some file extensions. You can do that by using any http handler available in .NET FCL, or if none can satisfy you then you need to roll out your own handler. You can do so in http module level, there're some authentication modules available in .NET FCL. Or again you can create your own http module. And of course, you also have another options to handle that in page level. Now the rdst to make decision is yours :o)
stevenbakerAuthor Commented:

>> Understand the concepts...
take that back then!

not entirely sure what you mean, but does sound like it could solve my issue (and therefore be very cool!)

what we want is:
- ANY request (regardless of extension) would check for authentication settings as defined in the appropriate web.config
- IF the user is not logged in and is required to be authenticated, they go to the login page (again, all set in web.config)
- Once logged in, the resource is delivered by the approipriate httphandler, as if it had been requested on a normal IIS server
so, to give examples:
.aspx (etc) - via asp.net process
.pdf, .doc, .xls, .xsl, .htm etc is just streamed down to client (ie works as on a standard IIS server)
.asp - via asp.dll

Is this sort of solution possible using built in or custom http handlers?

Thanks for the help
>> ANY request (regardless of extension)...
I don't think you really want to be doing that. It wouldn't be very fun as you need to have all incoming IIS requests map to the ASP.NET engine, lose one of your best security safe-guard (IIS) and you have to handle every possibilites yourself. Just map necessary file types to aspnet_isapi.dll.

>>IF the user is not logged in and is required to be authenticated...
Just leave it to FormsAuthentication if you don't need other authentication type, it can do a good job for you.

To get some ideas of what I've suggested above, please spend sometimes to read some of these articles.

Just keep in mind, implementing custom http handler or http modules is not too difficult, but it is not boringly easy either. There're certainly some caveats that need to be taken care of..mm..I guess we can discuss that later.
Forgot to mention, do some google for UrlAuthorizationModule, it might be useful also.
stevenbakerAuthor Commented:
Thanks for the pointers, think I've got enough to go on now and work out exactly what solution we should use.

Will post a comment back with details of the solution we take for anyone coming here looking for answers

ihenry, thanks again for the info.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

  • 6
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now