I'm relatively new to ASP.NET MVC, but I already did C# for a while and I already took the MVC basic course. What I'm stuck with is the "ASP.NET Membership".
For my website, I need a registration (with email, password, and some cstom fields), a login, "roles" (user, admin. moderator, etc...), "settings" (change password, etc ...) and cca. 40 custom fields (like date of birth, favorite color, car type, etc ...) connected to the user.
How should I make it in MVC?
I have found the SimpleMembership, but I don't need most of it's features, and the features I need are missing.
My time to shine!
I would recommend using the Entity Framework, because reasons. It makes DB interactions very simple and readable.
you can write your own membership provider in MVC, which like you said you wont need most of the features, so you dont need to implement them. This dude implemented it all here ->
http://www.brianlegg.com/post/2011/05/09/Implementing-your-own-RoleProvider-and-MembershipProvider-in-MVC-3.aspx
He tells which ones to focus on, and shows roles and authorization.
Essentially you will map a User model to your User table using the entity framework, then use that user model when the person is registering. You can even use validation attributes, as seen here->
http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validation-with-the-data-annotation-validators-cs
What other questions may I answer to help you on your journey today my good sir?
Personally, I like to use the built-in membership provider (have yet to look at the SimpleMembership) for the registration, login and roles.
I then simply create my own member tables that I tie together with the membership User table.
This simple approach prevents me from having to create my own membership provider, and I am free to define the member table the way I want.
Related
I am looking at migrating an old app to MVC4 but can't yet modify the database. The existing database already has it's own user / group / membership tables setup (in a rather quirky way might I add, but it works).
With the MVC3 style MembershipProviders I could roll my own extending what I needed to login, check role permissions, modify user attributes etc. but I'm at a loss as to how to achieve this with MVC4 and it's SimpleMembership and then how to use OpenAuth alongside it as an alternate way to login.
I've been looking around but there seems to be very little content online yet regarding it, any ideas?
I don't require a SimpleMembership implementation, if anyone is aware of another similar provider that would do too.
SimpleMembership is just like its name: simple. So if you want to extend the membership provider to meet your complex requirement of roles and membership, it's not a good choice. If you do really have to upgrade your app to mvc4, just do it, then reuse the ASP.Net Membership that exited in your app. It's still running properly on mvc4.
One thing to try is to just use SimpleMembership and add as many roles as you need to make up for your current "attributes". Depends on what you mean by "attributes". If you just want to add additional columns to the UsersProfile table, it's pretty easy to do. And then the SimpleMembership API can access those new columns just as it does the built-in ones in a default MVC4 Internet App. project.
Have you viewed this SO thread?
I'm learning ASP.NET MVC 3 to build a web application. I've followed a couple tutorials teaching the Entity framework, Razor, MVC, etc. One thing I can't find much about though is how to do authentication and authorization. In the tutorials I can find, it basically goes
Create an "Internet Application" project. The authorization system is already there so you don't need any code. Now use an ASP.NET settings panel to set up user roles and slap [Authorize] everywhere.
I understand the system it starts you off with is called ASP.NET Membership. Is it common to just stick with that for your authorization?
I've been using Code First to do models and databases -- is there a way I can create my own user models, have ASP.NET create the database, and use that for membership? How tough is it to customize user models (for example, if I want some user roles to have some information stored with their membership, but not others)?
Are there any tutorials that go through ASP.NET Membership in detail rather than just starting with whatever the project template spits out? For example, implementing it in an empty project?
It depends on the needs of your application. You will find the provided model has some limitations, but if you only need basic user/role management then it might suffice. Personally, I've always found it a bit too inflexible for my liking, but if it does what you need for the application your building, don't waste your time reinventing it.
Hope this helps.
You can extend the default membership behavior by adding a role provider which allows you to group users into one or more roles.
Furthermore you can extend the user's profile information to store additional information (although not specific to a role, so all profiles will have a slot for role-specific information). See this article by ScottGu for how to extend a profile: http://weblogs.asp.net/scottgu/archive/2005/10/18/427754.aspx.
i want to use asp.net membership provider for my own database i have own table
here is what have i done
i extended the membership provider class with my own write all overided methords.
is it right way to use membership provider class for custom use?? i also extend the rolemanagement class too.
What's "right" and what's "wrong" is hazy, as different people have different opinions.
My opinion is that you should never extend the membership tables, because by doing so you create potential problems down the road if Microsoft decides to add additional functionality to those classes.
Instead, you should simply use the asp.net membership provider keys as foreign keys into your own tables. Thus, you might have your own "users" table, but one of the columns is the asp.net membership User ID value. This allows you to relate them together and get at that information, without extending the asp.net membership tables themselves.
I have tried implementing custom membership user, and succeeded after a month's effort. One idea I always have is, no one can ever generalize what our requirements should be, and especially a vendor should not decide in particular.
It is good we have a way to extend the membership user. This and that are the best resources to guide how to write a membership user.
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.
I have a website that's sort of a Craiglist type app.
In my Database, should I create a table called UserRoles, and assign the UserRoleID as a Foreign Key to every user created? 1 for Admin(Complete Priveledges), 2 for Moderator, 3 for Normal User, etc.
Also, inside of my ASP.Net application, say I have a UserControl. Inside of that user controls method, should I ask if User.ID = "1" make a button X.Visible = True?
Say if the currently logged in user is an Admin, make a little red X appear so the Admin can easily delete a listing, etc.
Or is there a more established way to do this?
You have the right general idea of a roles provider there. Role providers give a user some level (or perhaps multiple levels) and then in your code you can validate the current user's level when displaying content and evaluating inputs.
If you are using your own system then what you have described above is a perfectly reasonable approach to authentication and authorization. However, if you are using the ASP.NET built-in MemberShipProvider and RoleProvider (which you probably should be!) then there are many tutorials on getting those up and running. Personally, I would recommend using an existing provider over reinventing the wheel, but that's just me. You'll find that the built in providers are very comprehensive and simple to use.
Roughly speaking that is how you would do it.
You should probably take a look at .Net Membership as it already provides most of the leg work to get this done.
Also rather than writing user.RoleID == 1, all over the place consider writing some methods/properties to answer the question for you.
e.g.
if(myuser.IsAdmin)
{
....
}
or
if(myuser.HasRightsTo(Rights.DoX))
{
....
}
ASP.NET 2.0 introduced Membership. It makes maintaining users, roles, and profiles rather simple. I would recommend using the default SQL implementations.