In MVC4 we had Simple Membership. My opinion is that Simple Membership was a good Identity Model tried and tested with good documentation and didn't need to be fixed but simply needed an upgrade in terms of Email Verification/ Password Reset and all other stuff that we normally have to deal with when building an app. However the new ASP.NET Identity model seems achieve Something of sorts that Vista achieved over XP. I mean AspnetUserClaims and AspnetLogins could have been bunched together as UserAliases. And Microsoft should have provided some methods for the Email part of my babble. Having just discussed my opinion based on first looks which might be deceiving my question is
I am trying to decide whether I should move from Simple Membership to the new ASP.NET Identity but since documentation and tests of ASP.NET Identity model is sparse, conflicting and hard to locate using Google. So can someone with experience of both please summarize the pros and cons?
#Roman references some good articles that looks at the pros and cons of ASP.NET Identity and the membership provider model.
ASP.NET Identity gets away from the membership provider model, which I believe is a good thing. There are some definite problems with Simple Membership when you wanted more advanced security features and if it was anything more than "simple" you ended up creating your own security solution. I am moving forward with ASP.NET Identity because it much more extensible than Simple Membership and although the documentation and support is weak right now I believe it will get better as it matures, just like Simple Membership did. If you can get past the growing pains I believe ASP.NET Identity will be a far better solution than Simple Membership was and I like the tight integration with OWIN, which will be important going forward. As for email verification with ASP.NET Identity, here is an article that describes how to implement this. You can get complete source code here. And the solution described here also provides password reset with ASP.NET Identity.
As for me, they are all quite far from being perfect. Check these out:
The good, the bad and the ugly of ASP.NET Identity
Think twice about using MembershipProvider (and
SimpleMembership).
So I prefer to use MembershipReboot.
EDIT: (May 2018). Brock Allen of MembershipReboot has the following, to say on the Project site.
As of 2017 MembershipReboot will no longer be maintained. It has
served its purpose, and ASP.NET Identity has finally caught up (and
surpassed) this library in terms of security and functionality. If you
are interested in taking over maintenance, let me know.
Related
I'm using SimpleMembershipProvider in and ASPNET MVC 4 applcation which uses WebApi, Entity Framework 5 and Code First.
I did it following this post, which seeds the database and seems to work.
My question is:
Is there any out of the box admin page to give or remove roles like admin from users?
If not, any suggestion?
Thanks! Guillermo.
No, sadly there isn't. On the bright side, you can create your own and it's designed to work well with EF. Simple Membership is far more flexible than the old .NET Membership.
This is a nice, though not exhaustive overview of simple membership and how to integrate it with EF Code-First.
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
This link guides you through the process of manually creating an admin (near bottom)
http://blog.osbornm.com/2010/07/21/using-simplemembership-with-asp-net-webpages/
In truth, classic Membership is more convenient to use 'out of the box'. setting up 'simpleMembership' is (ironically) heavy compared to the boxed older version. But, after all the OMG, you will probably find it to be a better solution.
SimpleMembership is designed to be customized, unlike previous SqlMembershipProvider versions. As such, an "out of the box" administration tool would not really work because the table layouts would be different from project to project.
I always used asp.net webforms with the MVP pattern, it works great for what I need, I basically create a project where all my business rules reside, validation etc... and I then implement my views in the webforms project.
Now we're starting to use asp.net MVC and using the MVP patter doesn't make much sense, right? So what could be a good approach to create a scalable and testable project using MVC that won't make me create my data objects and do validation on the controllers. I don' want to have the same code in different places...
If a web user wants to update his/her profile on the site, there would be some validation rules for when a submit button is pushed, like email address cannot be empty, must be valid and must not exist in the database.
These same rules should be applied if I try to update his profile using the internal admin section without having to duplicate the code there...
If you can point me to a good sample project that deals with this would be great!
Thanks in advance!
You should use the MVC pattern with ASP.Net MVC.
The NerdDinner tutorial is a pretty detailed example for MVC, you can also get a book that includes the tutorial (you might want to wait for the version that covers ASP.Net MVC 3). There are plenty of resources on Microsoft's ASP.Net site.
You can always consult Google.
ASP .NET MVC was built with the Model-View-Controller (MVC) pattern in mind. That would be the pattern you'd want to use.
In addition to the resources magnifico provided, I know others have recommended the some other tutorials. I don't know if these have been updated to the latest version of the framework, but they should still serve as decent beginners.
MVC Storefront series
MVC Music Store
Also the Microsoft Patterns & Practices group recently released Project Silk which gets into more advanced techniques involving a lot of AJAX management of the UI. There's interesting stuff there.
I am a new Asp.net Mvc programmer and I am developing a web site with the use of code first entity framework.
I know that there is a built in membership provider inside mvc project and even I can use custom membership provider in order to change it to my taste.
but I am not sure if it is better to forget about membership provider and implement all of them (login,authentication,...)by myself to have better integrity?
which is time consuming.
Could you plz tell me which one is better.
Regards
There is a SQL membership provider (http://msdn.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.aspx) that comes with the .NET framework that you can use. I would take a closer look at that. If it doesn't fit your needs, then build your own.
I always build my own as I like to have complete control over the data model. Most sites I work on, I only need to implement ValidateUser() in the membership provider, but what all you need to implement purely depends on what you are using the membership provider to do. I use the YAGNI approach when it comes to implementing providers. I only implement methods that I know are going to be called.
If this is for a product you are building, then I would go ahead and implement everything as you never know what other developers might use your product for.
ASP.NET Membership Provider is an excellent authentication framework. You can easily extend the framework by adding the membership provider to your database or building ontop of the existing database.
The ASP.NET Membership Provider has already done the hard work for you when it comes to authentication, state management, encryption, hashing, and roles, to name a few features. Why reinvent the wheel?
You can easily call pre-built ASP.NET membership functions and save yourself loads of work.
Aside from saving yourself time programming a new, possibly bug prone, authentication service, you would also be using a .NET industry standard. That means if you run into problems while using it, there have been many more before you that have already faced the same problems. You also make your authentication manageable, as because it's a standard, others will easility be able to pick it up and run with it.
I've read from a few individuals (Simone Chiaretta, Sebastien Lambla) that "you should remove the AccountController" from your ASP.NET MVC apps, but without much reason. I'm currently using it in one intranet site and am working on a second that will be considerably more widely used. What is wrong/bad about the default code that makes it undesirable?
Simone elaborates in comments. I have to disagree with him a little, though. Correctly implementing an authorization filter is not "easy." The first MVC previews got it wrong! In general, nothing which touches the area of security is "easy." However, the criticism of coupling is valid. Even if you use forms auth -- and you probably should use some off-the-shelf authentication if you're not a security expert -- the coupling is bad.
I need to write a forum application for a friend's web site. I want to write it in C# 3.0 against the ASP.NET MVC framework, with SQL Server database.
So, I've two questions:
Should I use Linq to SQL or the Entity Framework as a database abstraction?
Should I use the ASP.NET Membership API or add Users table and implement it myself?
Thanks.
There are lots of examples around internet which is using ling with ASP.NET MVC. But may be you can add your list NHibernate. If you do not want to add i suggest Entity Framework. Using ORM's is a plus.
I always chose write my own membership management layer. If you are a person like (write your own code and be happy when you are making changes in future.) write your own membership layer. If you are looking for a quick solution ASP.NET Membership API is a good choice.
Entity Framework definitely -- see below.
ASP.net Membership API -- easy to maintain.
Reason:
Entity Framework vs LINQ to SQL
1) How about both? Just create an abstraction and you could just use either. My recommendation is to use the repository pattern.
2) The membership provider has its strengths and weaknesses. For some projects, it was far too complex for my needs. However, it is great if you need to get something running in a short amount of time.
I won't answer the first question since i'm a fan of nhibernate
for the second question adding a users table and implement membership yourself i don't think you will be able to do it at least the right way (lot of people tried to make their own membership api but they messed up !)
1) Totally depends on how complex things are going to get. If you want a quick DAL that more or less mirrors your tables in a 1:1 fashion, go for L2S (or SubSonic if you want something more mature and supported). If you are going for more of an n-tier type thing where your tables and domain model are completely different, go for an OR/M like Entity Framework (or NHibernate if you want something that is pretty much better in every way)
2) ASP.net Membership is extremely complex, and there are bits of it that are fairly poorly engineered. However, it depends on how much experience you have with these things. If you enough to know how to take steps to avoid session fixation attacks, just roll your own because chances are it will be better then the canned solution. If you have no idea what that is, take the time to learn the default one.
Something to think about, SubSonic 3 is a pretty powerful data access generation tool. From what I understand, it basically wraps Linq to Sql inside of some very useful wrappers and makes using Linq a little more intutive. You can have a pretty powerful application built up in no time flat when using SubSonic. One little issue though, if you're using a shared hosting (say GoDaddy) you'll run into a medium trust issue. In that case you can always fall back to Linq To Sql without making many changes to your code base.
As for Aspnet_Membership. Just for the amount of tools it provides, I'd reccomend using it.
Good luck, and hope this helps.