Should I use a membership for this unusual accounting system
My asp.net mvc site needs some sort of authorization, but it is different from the usual concept of users and hence membership. It will be used more for preference and later for authentication. Accounts without a password must be available (and will initially be the only type), and an account can also be used by multiple users at the same time. Depending on the user group, it might be, for example, that all users in a particular region get a common account. This decision is from the client (marketing department) and is not negotiable.
A specific landing page accepts (only) a userId in the url that will load the account, which in turn has some settings associated with it that can be used throughout the rest of the site.
If the user does not start on the landing page, or the submitted account does not match the account on the system, he will be assigned a default account that has default settings.
I was thinking about not reinventing the wheel (someone has to find a new expression for this) and using the asp.net membership system. But the whole system is based on required passwords, email and separate sessions for each user, which I cannot provide. Since the situation is a bit unconventional, I thought a custom MemberhipProvider etc. Will be in place. But it seems that the gist of this is inheriting from regular membership classes. The methods of these classes all require things that I don't need.
Any suggestions
source to share
You can use the standard membership provider and use the Built in.Validate () method, which sends a username and password that is "standard" across all non-authenticated accounts.
You have two different user controls 1 for "Verified Login with Password" and one for "No Password Account", each uses the "Membership" account, but the last one must have a bit set in the member field that says "Public Account write = True / 1 "
Good luck, it seems like a fun project, it would be great to see the result;)
By the way, you don't need to share the session or could you just store the session in the database and display the session to the user, not the cookie, might work?
As requested, I will cover the various custom controls. In a nutshell, I would have two controls, one of which was possibly called GlobalLogin and one called UserLogin, where GlobalLogin displays a form that only has the username. When it is dispatched, it will call a function, which, as I said, uses a function that calls the Validate method on the membership provider with a preset password.
As a reflection, see all "Not logged in with password" - users are as anonymous and treat them the same, the only thing different is that they can access user-specific scopes. This control must also check that a specific field is set in the database, such as the "Allows a globally used account without a password" field, where in this case the bit / boolean must be true for that login to be accepted.
Now on the other hand, a control that handles password protected accounts requires a username and password to do so, and this triggers a check with these settings. Now remember that when logging in with a password, you can change your password, this MUST NOT be possible with a global account, because then your global password did not work :)
source to share
Details on the membership provider can be found at http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx . Basically you need to create a new provider, or get from an existing one and overload the ValidateUser method to always return true.
source to share