When was the default AccountController sample changed?

I asked this question on asp.net forums and no one seems to know what I'm talking about. I'm not sure why this is so, but I thought I would ask here to see if there is anyone with understanding.

Back when MVC2 was released, it included a sample AccountController that hooked the built-in Membership and FormsAuthentication classes with tested interfaces and services. I read a lot about this, and it was considered a good thing, because the Membership and FormsAuthentication classes were not easy to verify.

I recently generated a new sample project with an updated environment (SP1, MVC3, Tools Update, etc.), and I found that AccountController is now much simpler. Passed through the interfaces and services of MembershipService and FormsAuthenticationServices. The sample now calls the Membership and FormsAuthentication classes directly.

I am wondering if anyone knows when this happened and why? Are the tested interfaces no longer considered correct? Was there a technical reason to change this?

The best thing I can understand is that it happened as part of a change to remove a possible vulnerability when passing a return URL to an open URL.

Any insight?

+4
source share
2 answers

The account controller was changed using the MVC3 tools update (when they also included using jQuery via Nuget)

0
source

The new model resembles the first approach of the EF code, where AccountModel is the POCO class. There are no more abstractions inside the new API, but direct calls to static methods like FormsAuthentication.SetAuthCookie , which makes this code difficult for unit test. Not what I would recommend based on your real world application code.

And yes, they fixed a vulnerability inside the LogOn method that did not check if the returned url is a relative URL before being redirected.

Personally, I would recommend that you use abstractions to loosen the connection between the controller logic and its dependencies. This will simplify the unit test code.

For me, transferring all of these domain models to views without using view models is a common anti-pattern, and I never worried about them. I just create an empty project and do my own thing. I mean, in the default project, they even use ViewBag for Christ!

+3
source

All Articles