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.
Related
I’ve created a custom MembershipProvider that uses the DotNetNuke.Security.Membership.MembershipProvider as a base. In our implementation, a CRM system stores all contact data for users able to connect to any of our websites, and therefore such functionality as CreateUser and DeleteUser are not implemented. The MembershpProvider only handles authentication, membership and returning a UserInfo object with the CRM system’s data.
This works fine.
The problem I’m running into is with the PersonalizationController. Our CRM system stores information regarding the user/contact, but not regarding the user’s personalization settings. I would like for DNN to continue to store the personalization settings as defined in the PersonalizationController / PersonalizationModule (e.g., in the Profile table). The problem is, when the LoadProfile() stored procedure is called by the DataProvider it fails on an update because the Profile table has a constraint associated with it requiring the UserId to have already been added to the User table. I could modify this Foreign Key relationship but that wouldn’t be good architecture.
So, the question is: What would be a good architecture choice in this situation?
The MembershipProvider and DataProvider follow the Provider Model, so they can be replaced, but I don’t want to replace the DataProvider. The PersonalizationController doesn’t follow the Provider Model and therefore cannot be so easily replaced. Updating the Stored Procedure or the Foreign Key would potentially cause upgrade issues (or at least make debugging years later hard / require good documentation). Likewise with changing the source code (I could simply update the PersonalizationController, line DataProvider.Instance().AddProfile(userId, portalId); with a call to first add the user to the Users table (which should be unnecessary – yes, I understand the difference between the Users and aspnet_Users tables, so theoretically, adding a User record should be OK, albeit superfluous simply because of a Foreign Key. I could also update the MembershipProvider with an insert into the Users table -- this is the direction I'm currently thinking about (although I don't really want to).
Any ideas how I can replace the PersonalizationController using a Provider Model? Or how else I can minimize upgrade or management issues down the line? I’m really trying to build a system where we can at any time install DNN fresh and simply install all our Modules / Providers / Skins on it and replicate the existing system (without content, of course).
What would be the recommended way / recommended architecture in this situation?
Thanks in advance.
Greg
Would it make sense to keep the UserID in the DNN database, so that you can utilize all of those keys that many different modules may have on the Users table. If you don't have userids, it is very likely that you will run into module issues down the line.
The AD provider for DNN creates DNN users, and matches those up to AD users, to get around this issue.
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.
This is a beginner pattern question for a web forms-over-data sort of thing. I read Exposing database IDs - security risk? and the accepted answer has me thinking that this is a waste of time, but wait...
I have an MVC project referencing a business logic library, and an assembly of NHibernate SQL repositories referencing the same. If something forced my hand to go and reference those repositories directly from my controller codebase, I'd know what went wrong. But when those controllers talk in URL parameters with the database record IDs, does it only seem wrong?
I can't conceive of those IDs ever turning un-consumable (by MVC actions). I don't think I'd ever need two UI entities corresponding to the same row in the database. I don't intend for the controller to interpret the ID in any way. Surrogate keys would make zero difference. Still, I want to have the problem because assumptions about the ralational design aren't any better than layer-skipping dependencies.
How would you make a web application that only references the business logic assembly and talks in BL objects and GUIDs that only have meaning for that session, while the assembly persists transactions using database IDs?
You can encrypt or hash your ids if you want. Using session id as a salt. It depends on the context. A public shopping site you want the catalog pages to be clear an easily copyable. User account admin it's fine to encrypt the ids, so users can't url hack into someone else's account.
I would not consider this to be security by obscurity. If a malicious user has one compromised account they can look at all the form fields, url ids, and cookie values set while logged in as that user. They can then try using those when logged in as a different user to escalate permissions. But by protecting them using session id as a salt, you have locked that data down so it's only useful in one session. The pages can't even be bookmarked. Could they figure out your protection? Possibly. But likely they'd just move on to another site. Locking your car door doesn't actually keep anyone out of your car if they want to get in, but it makes it harder, so everyone does it.
I'm no security expert, but I have no problem exposing certain IDs to the user, those such as Product IDs, User IDs, and anything that the user could normally read, meaning if I display a product to the user, displaying its Product ID is not a problem.
Things that are internal to the system that the users do not directly interact with, like Transaction IDs, I do not display to the user, not in fear of them editing it somehow, but just because that is not information that is useful to them.
Quite often in forms, I would have the action point to "mysite.com/messages/view/5", where 5 is the message they want to view. In all of these actions, I always ensure that the user has access to view it (modify or delete, which ever functionality is required), by doing a simple database check and ensure the logged in user is equal to the messages owner.
Be very very very careful as parameter tampering can lead to data modification. Rules on 'who can access what ids' must be very very carefully built into your application when exposing these ids.
For instance, if you are updating an Order based on OrderId, include in your where clause for load and updates that :
where order.orderid=passedInOrderId and Order.CustomerId=
I developed an extension to help with stored ids in MVC available here:
http://mvcsecurity.codeplex.com/
Also I talk about this a bit in my security course at: Hack Proofing your ASP.NET MVC and Web Forms Applications
Other than those responses, sometimes it's good to use obvious id's so people can hack the url for the information they want. For example, www.music.com\artist\acdc or www.music.com\arist\smashing-pumpkins. If it's meaningful to your users and if you can increase the information the user understands from the page through the URL then all the better and especially if your market segment is young or tech savvy then use the id to your advantage. This will also boost your SEO.
I would say when it's not of use, then encode it. It only takes one developer one mistake to not check a customer id against a session and you expose your entire customer base.
But of course, your unit tests should catch that!
While you will find some people who say that IDs are just an implementation detail, in most systems you need a way of uniquely identifying a domain entity, and most likely you will generate an ID for that identifier. The fact that the ID is generated by the database is an implementation detail; but once it has been generated it becomes an attribute of the domain entity, and it is therefore perfectly reasonable to use it wherever you need to reference the entity.
After I was learning about ASP .NET Membership built-in framework I have decided that this stuff is almost suitable for me. But there are couple features and edits I would like to have:
Two step registration: after user have typed all account information, verification letter should be send to typed email. Before email address is verified it impossible to log in (some message should appear, telling user that email verification is needed before it's allowed to use account).
Membership DB Scheme:
There is no need to store user question for restoring password.
Illegal attempts to login is uneccessary.
Default aspnet_ prefix is likely to be changed.
... and so on
For the first item I know that I could use own class derived from SqlMembershipProvider. Am I right about this? Could you point me at some good post where I could get learned.
For the second improvement it's seems like a trouble. In this book I have read that isn't so easy:
• The built-in SQL storage providers need direct access to your database, which
feels a bit dirty if you have a strong concept of a domain model or use a particular
ORM technology elsewhere.
• The built-in SQL storage providers demand a specific data schema
that isn’t easy to share with the rest of your application’s data
schema.
The biggest problem I've encountered with subclassing SqlMembershipProvider is it doesn't give you the connection string to work with. You have to hack the class to pieces to get anything useful for the way most modern login systems work.
I'm not sure about the database tables names - I don't think that's controlled by the SqlMembershipProvider but is actually inside an ASP.NET installer class.
My advice would be to create your own from scratch, and use the built in FormsAuthentication helpers. It's really not a big task compared to hours of annoyance having to conform to the providers. I did this with Roadkill after going down the Membership Provider route, and discovering it a cul-de-sac particularly for Active Directory support.
You can completely control your membership DB schema by Implementing Custom Membership User (of course you also need to implement Membership Provider for the User).
Customize user creation steps by configuring CreateUserWizard control. You will change its' template and handle events, I don't think you need to override it.
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.