Databases Reference
In-Depth Information
<location path=”
SUPPLIERS
”>
<system.web>
<authorization>
<allow roles=”Manager, Employee”/>
<
deny users
=”*”/>
</authorization>
</system.web>
</location>
You can define the same authorization rules by applying the
AuthorizationAttribute
to
the Supplier entity class, as shown here:
[Authorization(
Allow.Roles, “Manager”, “Employee”,
Deny.Users, “*”)]
partial class Supplier { ... }
The
AuthorizationAttribute
constructor takes an open array of parameters, which can be
used to define one or more authorization rules. Rules start with values from one of the
two enumerated types—
Allow
or
Deny
, both of which have the same two items defined,
Roles
and
Users
. In other words, the rules begin with
Allow.Users
,
Allow.Roles
,
Deny.Users
, or
Deny.Roles
, followed by one or more strings that specify names of users or
roles, respectively. This allows you to mimic the web configuration rules such as
<allow
roles=”…”/>
with C# code that looks like this:
Allow.Roles, “…”
.
Although this is not a
requirement, by convention, you place different rules on different lines of code to make
the rules easier to read.
NOTE
Only one instance of the
AuthorizationAttribute
is allowed per class. Having to
define multiple authorization rules in a single attribute is not ideal. It would be much
cleaner if you could define authorization rules with separate
Allow
and
Deny
attributes,
similar to this:
[Allow(Roles = “Manager, Employee”)]
[Deny(Users = “*”)]
partial class Supplier { ... }
Unfortunately, the .NET runtime does not guarantee that the order of attributes
retrieved via reflection match the order of attributes in code. In this example, the
Deny
attribute could have been returned first, which would deny access to all users.
The .NET Framework also prevents attributes from having properties of user-defined
types, which rules out the possibility of defining the authorization rules as custom
Allow or Deny classes and using them similar to this:
