Please note - authorization or other security decisions must never
be made based on the current area, e.g. examining the current route to determine which area the current request belongs to. The only supported way of accomplishing this is to put an [Authorize] or other similar filter
which doesn't depend on the current area on a base controller, then making sure that each controller within an area subclasses that base controller.
Your first code sample is vulnerable because it tries to get information (like the area name) from the route servicing the request. This makes the route itself responsible for the security decision, which is a Very Bad Thing since Routing can be bypassed.
Your second code sample should be fine because you've statically included the name as part of the attribute, so what you're doing is really no different than [Authorize] with a custom redirect URL.
Subtle but important difference. :)
Marked as answer by ricka6 on Mar 09, 2010 09:08 PM
levib
Star
7702 Points
1099 Posts
Microsoft
Re: Bit lost on first custom Authorization Attribute
Mar 02, 2010 07:24 AM|LINK
Please note - authorization or other security decisions must never be made based on the current area, e.g. examining the current route to determine which area the current request belongs to. The only supported way of accomplishing this is to put an [Authorize] or other similar filter which doesn't depend on the current area on a base controller, then making sure that each controller within an area subclasses that base controller.
Your first code sample is vulnerable because it tries to get information (like the area name) from the route servicing the request. This makes the route itself responsible for the security decision, which is a Very Bad Thing since Routing can be bypassed.
Your second code sample should be fine because you've statically included the name as part of the attribute, so what you're doing is really no different than [Authorize] with a custom redirect URL.
Subtle but important difference. :)