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.
Related
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.
I'm creating a custom authentication service (I just need more than the default allows). I can't decide if I should extend MembershipUser and implement the appropriate interfaces, or completely roll my own. Is there any advantaged to rolling my own, or any pitfalls I should be aware of when extending the default mechanism?
How far from defaults are you?
If your needs are far apart from what MembershipProvider gives you, I suggest you go with your own. I personally haven't come across an application that connected to an existing data store. So we would be adding another application to it. Hence I find MembershipProvider way over engineered. Authentication/Authorisation usually also doesn't take too much time to develop and you control it completely. If it does take a lot of time it's probably also far from what MembershipProvider gives you.
But if your requirements are close to MembershipProvider, then you should consider it. Either as it is or derive from it on your own. But beware. This may take more time than delivering your own, because you will have to learn it through and through.
Security management requirements
If you go with MembershipProvider (or your own inherited class) you also get IIS integration so it's easy to manage security settings of your application. If you roll your own, you'll have to provide an interface for that as well which may take a considerable amount of time.
Implement MembershipProvider abstract class. I have an implementation with XML as datastore right here, if you need it.
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx?queryresult=true
Its always good fun to write your own provider but it depends on the security needs of the application you are building.
Most occasions when I have had to implement my own provider.
Using an orm such as nhibernate.
No database so requried to use flat xml files.
I had to build a system that required a more extensive role-permission system than the membership classes provided.
Good thing is you can switch between different providers if you need too..
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.
For some reason, the idea of setting up Membership in ASP.NET MVC seems really confusing.
Can anyone provide some clear steps to setup the requisite tables, controllers, classes, etc needed to have a working Membership provider?
I know that the Demo that MVC ships with has an Accounts controller. However, should I be using this in my own project? What do I need to get my existing database ready if so? If not, how do I learn what I need to do to implement a membership provider?
Check out this step by step blog on how to set up Membership provider in your asp.net mvc project. The sdk tool you need to get your database ready is aspnet_regsql.exe, you don't need to create a separate database to do that ( a lot of people think they have to provide a separate aspnet.db), you can run the command on your existing database, and it will create the tables, views, and stored procedures to handle the membership provider for you.
However, should I be using this in my
own project? What do I need to get my
existing database ready if so? If not,
how do I learn what I need to do to
implement a membership provider?
The benefit to use the default provider (SqlMembership provider) is to save yourself a lot of time. It involves a lot of work to design a complete membership and role provider.
Edit [2014-06-19] Asp.Net Identity Framework is Microsoft new recommendation to manage user sand permissions.
Check out this link:
https://github.com/TroyGoode/MembershipStarterKit
Most of the work is already done for you. Just download the sample project and run the aspnet_regsql.exe against your database.
check out my answer in this post;
membership
If you want to keep the membership provider that .Net creates for you then you can copy all the tables etc to another sql database and point the provider at it via the config file.
Post a comment if you need more than this.
How would you handle membership in an ASP.NET MVC application? Using any external libraries? How would you do OpenID log in? username log in? email log in? any other that is worth looking into? Maybe all of them mixed into the application?
It seems ASP.NET comes with some pre-build user database (I'm totally new to .Net). The NerdDinner example uses it but then it makes the foreign keys use the username. That doesn't sound very good. Do you use this schema of two separate databases or only one? What do you use as the foreign key, any IDs?
I've found ASP.Net MVC Membership, anybody using it? does it work well? can it be expected to be maintained?
Membership Providers are not new to ASP.Net MVC, they were introduced with ASP.Net 2.0.
The Membership Provider model is simply an abstraction layer between your application and whatever source you are authenticating your users against. You can switch providers easily by simply changing your web.config file.
It is easy to write a membership provider, there are many walkthroughs on the web. Typically you would do so if you were using a database that used a different schema than the default examples that come with ASP.Net (which is most of the time). The foreign keys on the username thing in the NerdDinner example is a simplistic example that you would rarely see on any real-world databases.
I would highly recommend using the Membership model. Controls like the Login control are built to make use of it, and it is well-designed and makes it easy to change or combine different login methods for your application. If you want to use OpenID, a quick google search brought up this OpenID Membership Provider.