Databases Reference
In-Depth Information
words, managers will be allowed to access all dynamic pages for the Customer entity, and
employees will be able to access only its List page.
<location path=”
Customers/List.aspx
”>
<system.web>
<authorization>
<allow roles=”Employee”/>
</authorization>
</system.web>
</location>
When processing authorization rules, ASP.NET starts with the
<authorization/>
section
closest to the URL in question. If no matching rule is found, it continues with the next
available parent configuration until it finds a matching rule. This works the same with
both physical Web.config files and
<location/>
elements as well. In this particular
example, when an unauthenticated user is trying to access the
Customers/List.aspx
,
ASP.NET first evaluates the
<allow roles=”Employee”/>
rule defined specifically for this
dynamic page. Because the rule does not match the unauthenticated user, ASP.NET contin-
ues with the
<allow roles=”Manager”/>
rule defined for the dynamic Customers folder.
Because this rule does not match either, it then evaluates the
<deny users=”*”/>
rule
defined for the folder. This last rule does match, and ASP.NET denies the unauthenticated
user access to the dynamic
Customers/List.aspx
page.
NOTE
If a matching authorization rule cannot be found all the way up to the root of the web
application, ASP.NET
allows
access by default. In a dynamic web application, where new
entities can be added without creating physical folders, it is easier to overlook missing
authorization rules and allow access by accident. If you want to rely on Web.config files
to implement security, you might want to deny access by default as a precaution. Here
is an example that does that:
<?xml version=”1.0”?>
<configuration>
<location path=”Default.aspx”>
<system.web>
<authorization>
<allow users=”*”/>
</authorization>
</system.web>
</location>
<system.web>
<authorization>
<deny users=”*”/>
</authorization>
</system.web>
</configuration>
