Yes hashing is better but...
So I knew I would regret this but here we go. I started a new project and decided I would use the built-in Microsoft membership stuff in MVC 4 (BasicMembership) so that I didn't have to write the registration, login, oauth, etc...
Now I want to modify some of this behavior and use as much best practice as possible. This came about because I decided I would need to associate multiple users under 1 parent (company) - I know I can do all of the work in the controller and still accomplish this, but that is not my desire.
Here is my problem/desire:
1.) I want to create the entries in SQL tables UserProfile/WebPages_Membership myself. I want to do this in my repository and I don't want it to be coupled to ASP.NET. The problem is that MVC is encrypting the password via IMembershipAdapter that I do not have access to. How can I use the same encryption key to encrypt the data so that I can accomplish #2?
2.) I dont want to re-invent the wheel entirely so I would still like to use some of the features such as:
WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe)
3.) I don't want my business logic in the controller! While I am working at the repo level, all of the orchestration will take place in the business tier.
Thanks for taking the time to read my post :-)
First of all did you look at: ASP.NET MembershipProvider -- How exactly does it do encryption?
Second thig maybe use something already done like: CodeFirst Membership Provider it allows you to create own tables using EF code first.
Related
We are looking to move our application to using the new SimpleMembership included in ASP.NET MVC 4 but we currently have multiple applications using the AspNet_Applications table of the old membership provider.
The reasons we are looking to move are the obvious ones, SimpleMembership is much smaller and we can map directly to our user table and also we want to start using OAuthWebSecurity.
Is there anyway to introduce this support by either extending SimpleMembershipProvider or even ExtendedMembershipProvider to allow multiple applications in the same database.
Alternatively should we just write our own membership which we can then use OAuthWebSecurity with without it using the webpages_ tables?
Would prefixing the username with an application name work?
Instead of user#example.com you would have 5|user#example.com or whatever format you chose. As long as you do this every time you read or write to the SimpleMembership table you'd be fine.
Create your own little abstration wrapper and I think you should be good to go. If you find any issues would be interested to hear them since I'm considering doing this myself too.
I have been doing some research about how to do custom profileprovider in .NET MVC.
It seems pretty complicated. Is there any other alternative?
And this is my major concern, why do ppl bother using customer profileprovider? If they want extra information about a user, why don't they just make another table with OneToOne relationship with aspnet_Users with userId or userName as the foreign key?
Please clarify. I'm trying to implement user profile functionality, but I don't wanna go down the wrong path.
Thanks
DG
(not to sure if this helps talk about custom profile providers.. unless I'm misunderstood...)
IMO, what ever you do .. avoid (the baked in) ASP.NET Membership at any cost! It's sooooo over engineered, you'll want to stab yourself in the eye with a blunt spoon :(
Trust me. avoid it.
Why: Should I use the built-in membership provider for an ASP .NET MVC application?
So .. what can we do instead?
It's just so simple to roll your own Username/Password and leverage the built in Forms Authentication. For myself, I'm not a fan of storing -any- passwords in my own database .. so i prefer to use Facebook, Twitter or OAuth as my mechanism for authentication .. which then means I finish up with a simple, basic, custom user class.
I also create my own custom IPrincipal and IIdentity because I want to store a bit more info in the cookie, which Forms Auth creates when a person has been authenticated. This then helps keep my code in my Controllers cleaner and way simpler.
For example, I store the userId of the authenticated person in an encrypted cookie. (the default option is to only store a Name). I also store one or two more things .. but you get the idea. This way, I don't always have the hit the DB to retrieve any user data OR store this crap in a session.
With a roll your own, u can create extra meta data (birthday? mum's maiden name? social security number (joke) ) .. and have that extra profile data. Same table? extra table? who cares ... that's a decision to make way later (and EASY to solve). Get your model right, IMO :) Then once u've locked down your model, you now know what's required and what's optional .. and u can make some DB decisions then.
TLDR??
Avoid the built in ASP.NET Membership crap
Roll your own .. and keep it simple.
If you're feeling advanced, also roll your own IPrincipal and IIdentidy to really rock your world.
GL HF and don't stab yourself with a blunt spoon, in your eye!
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.
For my ASP.NET MVC app, I just find dealing with unique-identifiers harder, so I have added my own field to ASPNET_USERS table - UserIdInt (which is actually a bigint!) So most of user operations use userIdInt as reference.
Anyway, I am debating between two approaches:
1)When a user logs in, look up from the database and store the userIdInt in a session variable and any-time session variable slips away, re-look it up and put it back in session variable. (It's okay to use sessions in MVC app, right?)
2)Any time an operation needs to be performed, simply pass userName to database and take care of UserIdInt at database side by doing joins and such on ASPNET_Users table any time an operation from user needs to be performed.
I am heavily leaning towards 1)... but I want to make sure I am on right track.
I asked this question on Serverfault first, but I was told to ask this question here.
progtick,
you may be far better looking into the use of custom profile providers as this would allow you to leave the aspnet_* tables as is (which is a good idea in case a later version of sqlserver changes how they operate) plus offer the additional bebnefit of having a multitude of additonal profile related properties availabale to your application. i can't overstate enough the benefits in going down this track as i've found it very useful to have such an approach in both my standard asp.net apps as well as my mvc ones.
you can get a feel for what's involved in this by looking thro a couple of these links:
here's one on SO for starters:
Implementing Profile Provider in ASP.NET MVC
and one from my old mate, lee dumond:
http://leedumond.com/blog/asp-net-profiles-in-web-application-projects/
hope this helps
An alternative approach is to alter the forms authentication ticket to add your unique id to the data stored in the cookie. Then, by implementing a custom IPrincipal you can have your unique id available anywhere that the User object is available.
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.