MVC membership, authorization, and security

Require login with authorize feature

Requires users who log on to the system to access which URLs are specified by the application. We can do this by using the authorize action filter on the controller or on a specific operation within the controller.

Authorize: feature is the default authorization filter that is available with ASP. NET MVC, which can be used to restrict user access to the action method. Applying this feature to the controller allows you to quickly apply it to each action method in the controller.

1.Authorize usage in Forms authentication and AccountController controllers

*asp.net MVC's Internet applicaton template contains a basic AccountController that supports account management for membership and OAuth authentication.

The *authorize feature is a filter, which means that it takes precedence over the execution of the associated controller operation. That is, the authorize feature first performs its primary operation in the Onauthorization method, and if the user fails to authenticate, it will produce an HTTP 401 (unauthorized) status code and redirect to the landing page defined in the application Web. config file as follows:

<authentication mode= "Forms" >

<forms loginurl= "~/account/logon" timeout= "2880" >

</authentication>

This redirect address contains a return URL so that the Account/logon operation can be redirected to the original request page after the system is successfully logged in.

All actions in the Add attribute [authorize] on *checkoutcontroller allow registered users access, but prohibit anonymous access.

Require role members to use the authorize attribute

Fh

The use of security vectors in Web applications

Fh

Defensive coding

Fh

Summarize

* Always 宎 wake up any data provided by the user

* When rendering data that is introduced as user input, HTML-encodes it, and if the data is displayed as an attribute value, it should be HTML-encoded (Html-attribute-encode))

* Consider the parts of the site that allow anonymous access, those that require authenticated access

* Do not attempt to purify the user's HTML input (using white list or other method)--otherwise it will fail

* Use http-only cookies when you do not need to access Cookic through client script (in most cases)

* Keep in mind that external input is not a form field that is displayed because it includes URL query strings, hidden form fields, Ajax requests, and external Web service results we use, etc.

* AntiXSS Library (Www.codeplex.com/AntiXSS) is highly recommended