3

Our application is using forms authentication and the solution has been working well.

Recently one of our 2008 servers developed a problem where the authorization is not being propagated to subdirectories. In other words in the main web.config we have the following authorization settings.

<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

This causes a redirect to the login page for unauthenticated users (pretty standard).

The stylesheets are in the subdirectory /Content/Styles and the Contents directory has another web.config that overrides the authorization with the following:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.web>
        <authorization>
            <allow users="?" />
        </authorization>
    </system.web>
</configuration>

This should allow access to the stylesheets directory for unauthenticated users (also pretty standard).

The problem is that the server requests for stylesheets are being redirected to the login page.

I have tried removing the site and application pools and rebuilding them and I have also removed the IIS Role from the server including WAS (windows process activation service) and reinstalled. Neither of these resolved the problem.

I know the configuration is correct because I can take the same application and drop it on a new install of Server 2008 and it works.

Any idea how I can fix this problem without rebuilding the entire machine?

2 Answers 2

3

This problem was ultimately caused because the directory where the files were hosted was not accessible to the IUSR account (this was despite the fact that it was accessible to "NETWORK SERVICE" and the application pool identity). When I was testing on a fresh IIS7 installation I was copying the directory tree into \inetpub\wwwroot where IUSR already had access.

It still isn't clear why this problem exhibited itself as a redirect to the login page (as though it was not propagating authorization settings properly) but I did identify some problems with the configuration of forms authentication.

This part is critical because everything I have found doesn't correctly (or adequately) explain this.

Virtually everywhere I searched I found the following settings for web.config.

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="~/login.aspx" />
    </authentication>
    <authorization>
      <deny users="?" />
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

The way this is generally explained is that this unauthenticated users are redirected to login.aspx and authenticated users are granted access.

In fact, this configuration section only applies to ASP.NET pages (aspx). Any other types of content (html, asp, jpg, etc) are not governed by this configuration.

To protect these types of content you must have "IIS 7 URL Authorization" installed and it requires the web.config section under as shown below.

<system.webServer>
  <security>
    <authorization>
      <clear />
      <add accessType="Deny" users="?" />
      <add accessType="Allow" users="*" />
    </authorization>
  </security>
</system.webServer>

I saw one place that explained the difference between and as IIS6 vs IIS7 but this isn't completely accurate. There are different authorization mechanisms for different types of content and You need both if you want to restrict access to non aspx pages.

1

One idea coming to my mind is that there is another web.config file in your "styles" subfolder which contains another <deny users="?"> rule.

There is a discussion on the following forums thread that could be interersting to you: Problem with web.config inheritance and <authorization> section.

This MSDN article contains an interesting sentence. I'm not sure how to interpret it:

Rules contained in application-level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules (those nearest in the hierarchy) at the head of the list.

2
  • I agree, this is the first thing I'd check as well. That interesting sentence means that your lower-level .config files will trump the settings defined in .config files higher up in the site structure. Many applications can be defined under one site and this lets you set a base-line configuration for the site while still allowing individual apps within the site to have their own settings.
    – squillman
    Jun 10, 2009 at 21:00
  • There isn't another web.config file in the Styles directory. I'm sure it is configured correctly because I can copy up the directory, drop it on another machine and point it to this directory and it works. I'm fairly certain it is something messed up on this machine.
    – RonnBlack
    Jun 10, 2009 at 21:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .