o_19mgorv9t13a3ko71fev19l81mqa.pdf

Figure 12-1. The effect of the Authorize filter
When you try to access the Index action method of the Admin controller, the MVC Framework detects the
Authorize filter. Because you have not been authenticated, you are redirected to the URL specified in the Web.config
forms authentication section: /Account/Login. I have not created the Account controller yet (which is what causes
the error shown in the figure), but the fact that the MVC Framework has tried to redirect the request shows that the
Authorize filter is working.
Creating the Authentication Provider
Using the forms authentication feature requires calls to two static methods of the
System.Web.Security.FormsAuthentication class:
The Authenticate method validates credentials supplied by the user.
The SetAuthCookie method adds a cookie to the response to the browser, so that users do not need to authenticate
every time they make a request.
The problem with calling static methods from within action methods is that it makes unit testing the controller difficult: mocking
frameworks typically mock only instance members. The classes that comprise the MVC Framework have been designed with unit
testing in mind, but the FormsAuthentication class predates the unit testing-friendly design of MVC.
The best way to address the problem is to decouple the controller from the static methods using an interface, which offers the
additional benefit that this fits in with the broader MVC design pattern and makes it easier to switch to a different authentication
system later.
I start by defining the authentication provider interface. Create a new folder called Abstract in the Infrastructure
folder of the SportsStore.WebUI project and add a new interface called IAuthProvider. The contents of this
interface are shown in Listing 12-4.
304