IanG on Tap

It seems I spoke to soon when I said that putting your URL rewriting in the AuthorizeRequest event handler would allow ASP.NET's UrlAuthorization to work. This turns out to be only partly true because of a strange quirk in the way ASP.NET handles configuration files.

If you add an entry to your config file of this form:

<location path="/protected">
    <system.web>
        <authorization>
            <deny users="?" />
            <allow users="*" />
        </authorization>
    </system.web>
</location>

it will behave as expected: users must be authenticated in order to access URLs of the form /protected/*. However, if you add something like this:

<location path="/xx/alsoprotected">
    <system.web>
        <authorization>
            <deny users="?" />
            <allow users="*" />
        </authorization>
    </system.web>
</location>

you might reasonably expect, say, /xx/alsoprotected/foo.aspx to require authentication, but /xx/notprotected/bar.aspx not to require authentication (assuming that there aren't any other configuration entries around that protect /xx/notprotected).

And if you're using a normal physical layout for your web site, you'd be right. However, if you're using URL rewriting and you don't actually have a physical xx directory on disk, this won't work. If that directory isn't there, then ASP.NET doesn't recognise the <location path="/xx/alsoprotected"> as applying to the URL /xx/alsoprotected/foo.aspx. In fact as far as I can tell it will never pay any attention to the contents of that particular location element.

Note that it is sufficient just to create the xx directory in order to fix this. (It's not necessary to have the xx/alsoprotected directory.) In other words, as long as a physical directory exists for a particular path, location elements for any paths one level below this will be honoured, but not for paths more than one level below.

This feels like a bug to me. What business does a 'URL' authorization module have requiring me to have my physical directory structure bear a partial resemblance to my logical URL structure? (The fact that it only requires some of the physical directory structure to be presence seems to indicate a certain lack of conceptual integrity to the behaviour. This reinforces my feeling that this is a bug.)

On a related note, Keith Brown pointed out another potentially undesirable feature of rewriting the URLs in the AuthorizeRequest event. He points out that this will render the FileAuthorization module useless. For my particular application this is not a problem, as I have no use for the FileAuthorization module in my application. But if you were using a URL rewriting scheme simply to tidy up your URLs, but still mapping down to one physical file for each distinct URL, you might want to apply file authorization. That's should be much easier to fix than the problem described above: just move the rewrite to the AuthenticateRequest event.