How can i extend Users table of ASP.Net 4 membership - c#

I want to extend the users table of ASP.Net 4 memberships as below picture
So when the user register on the website i can control the extra columns ("WaitingApprovalRevenue", "ApprovedRevenue" and "WithdrawnRevenue")
Or i should play with default asp.net users table ?!!

You can use the Profile provider, but there is a drawback to the default ASP.NET one where it basically stores all the values in a single field. This makes it hard when you have something outside of the ASP.NET environment which needs to use those values (eg. for reporting purposes).
If that's not a problem, use Profile as Tim has linked, otherwise I would create a separate table with the user GUID as a key and just link it that way.

Related

MVC5 WebSecurity, use secondary database temporarily

I have a solution with two MVC projects. The first is a management system, the second is a portal for contractors. I want to manage the contractor login of the portal via the main application.
The membership database for both projects is identical in schema (the default). My thought was to hijack the main system's Register action, swap out the connection string, register the contractor user in its' own database, then swap the connection string back to the main one.
I'm guessing this won't work, namely based on the fact that WebSecurity.InitializeDatabaseConnection() can only be called once.
Thus my question: if I want to call the WebSecurity.CreateUserAndAccount() method but point it to a different database than what it was originally initialized for, how would I do so?
I looked at the built-in InitializeSimpleMembership filter for clues, but am not seeing the path I'm looking for.
Is this even a feasible approach?
Alternatively, if I can get the password hashed per the same way it's done by default, it looks like I can enter the required data to the db manually.
It appears I can manually work this out. According to the msdn docs for WebSecurity.CreateUserAndAccount():
This method creates a new entry in the user profile table and then a corresponding entry in the membership table. The ID of the membership entry is based on the ID of the user profile entry. (The IDs of the entries in the two tables match.)
(https://msdn.microsoft.com/en-us/library/webmatrix.webdata.websecurity.createuserandaccount(v=vs.111).aspx)
Inspecting the database schema shows that I only need two tables for this, and the fields are straigtforward.
To hash the password according to the same way the SimpleMembershipProvider does, I can use the System.Web.Helpers.Crypo.HashPassword() method.
This simplifies the basic account creation considerably as I don't have to piggyback off the AccountController and can just write these directly to the db and call it good (for my purposes, anyway, not requiring verification tokens and having seperately handled email notifications). On the portal side, the built-in SimpleMembershipProvider should be able to handle everything as usual.

Associate MembershipUser with Another Class

I am working on a project where I am using the membershipuser for authentication, but based on the role of the user I am going to need additional information (different for each role). I know I can extend the membership user in different ways, but I am also wondering if I should just create another class for these additional fields and just use the guid of the membershipuser to find this information. Any thoughts on this would be appreciated.
Wade
Based on tag in OP, you are using legacy ASP.Net Membership Provider or ASP.Net Universal Provider.
If so, the easiest way will be to create separate table. Then add foreign key to your tables.
Note: If you add columns to Membership tables, you will need to create Custom Membership Provider. In other words, Default Membership Provider will not work if you add columns to their tables.
If you are developing new application, you might want to look at ASP.Net Identity 2 which allows to add custom columns to their tables.

Is it possible to implement user profiles without using SimpleMembership?

I need some advice. I'm currently using MVC 4 & SimpleMemberhip with LDAP to authenticate users. The issue is, I don't want to store their usernames and passwords in the
webpages_Membership table due to security concerns. The second issue is I want to provide user-editable profiles.
Here's what works so far:
User logs for the first time and a new entry is created in webpages_Membership
An individualized link to edit the user profile is displayed on the homepage
Username is added to the UserProfiles table when profile is accessed for the first time
Certain user details are fetched from LDAP server and written to profile
Users can then customize their profiles
I'm currently using SimpleMembership with an override to the ValidateUser method. Everything works as it should but I don't need to store the LDAP usernames & passwords. Can this be done?
p.s. I know there is a better way to create new users & profiles besides on first time log in but I'm still working on it.
If you don't want to store the passwords (which SimpleMembership would do by default), you are better off deriving your own custom provider from ExtendedMembershipProvider (or maybe from SimpleMembership, but that would get complex) and write the LDAP implementation, or using one of the ones on NuGet. There's no built-in LDAP support in SimpleMembership, so any approach you do would be a nasty hack which will probably bite you later on.
As for the UserProfile, it doesn't sound like your requirement is that different to the usual UserProfile use case - create custom properties on the UserProfile model, update the database accordingly, and build a UI to allow the user to edit whichever of those properties they should be able to directly edit.
(edit)
Footnote. In my answer to "How do I use my own database with SimpleMembership and WebSecurity? What is MVC4 security all about?" I examine the history of membership, how ExtendedMembershipProvider fits into this, and how the new classes such as WebSecurity work on the basis of a provider being a concrete implementation of ExtendedMembershipProvider (which SimpleMembershipProvider is, for example). For anyone looking to derive their own provider to use with WebSecurity, that answer is worth reading.
I've managed to bypass storing user details in the Membership provider by creating the required tables with Code First. I'm now able to create new users and store them in the UserProfile table.

MVC 3 Code first First with built-in membership authentication

I would like to use code first EF 4.1 to build my application. I'm using MVC 3. I would simultaneously like to use Membership authentication. The problem I see mainly is how do I do a foreign key to the membership users table that was generated by the tool, to the model i'm creating via code.
for example:
dbo.aspnet_Users which has a guid as it's PK
I want to create a user in MY user table (dbo.Users) with the same GUID as my PK.
Is there a way to form that association without it just being implied by the matching data?
I'm not quiete sure what you are trying to achieve. If you want to associate custom data to a user, you could use the profile.
Is there a special reason why you like to sort of "douplicate" some user information?

ASP.NET: Custom MembershipProvider with a custom user table

I've recently started tinkering with ASP.NET MVC, but this question should apply to classic ASP.NET as well. For what it's worth, I don't know very much about forms authentication and membership providers either.
I'm trying to write my own MembershipProvider which will be connected to my own custom user table in my database. My user table contains all of the basic user information such as usernames, passwords, password salts, e-mail addresses and so on, but also information such as first name, last name and country of residence.
As far as I understand, the standard way of doing this in ASP.NET is to create a user table
without the extra information and then a "profile" table with the extra information. However, this doesn't sound very good to me, because whenever I need to access that extra information I would have to make one extra database query to get it.
I read in the book "Pro ASP.NET 3.5 in C# 2008" that having a separate table for the profiles is not a very good idea if you need to access the profile table a lot and have many different pages in your website.
Now for the problem at hand... As I said, I'm writing my own custom MembershipProvider subclass and it's going pretty well so far, but now I've come to realize that the CreateUser doesn't allow me to create users in the way I'd like. The method only takes a fixed number of arguments and first name, last name and country of residence are not part of them.
So how would I create an entry for the new user in my custom table without this information at hand in CreateUser of my MembershipProvider?
I think you should go on with your approach and add a new function in your implementation, I mean, overload the CreateUser method and have a CustomMembershipUser (that extends the MembershipUser) as a parameter.
In that way, before using the provider, cast it to your CustomMembershipProvider and use the overloaded method.
I agree with your analysis that you should keep both membership and profile information in the same table. Since you are correct that you are restricted by the number of parameters that CreateUser takes, you will need to design your field so that non-membership profile attributes are nullable. This does not mean that you will have required fields that are null in the database, however. Instead, you can you the below snippet:
string username = .../ retrieve username here
Membership.CreateUser(username , password, email);
ProfileBase newProfile = Profile.Create(username); //since the user has just been created, all properties will be blank
//set all entered properties
newProfile.SetPropertyValue("MyProp1", myProp1Value);
...
newProfile.SetPropertyValue("MyPropN", myPropNValue);
newProfile.Save();
In this way, you leverage ASP.NET's membership providers to create the user and save profile data, but to your end user it is a single atomic operation.

Categories