I only want to use CreateUserWizard Control to collect information from the user and insert into my custom database. I don't want to use Asp.Net Membership .
When I add this setting to the web.config
<membership>
<providers>
<clear />
</providers>
</membership>
The following error comes
Default Membership Provider must be specified.
And when I remove this setting from the web.config. The page runs successfully BUT createUserWizard Control automatically adds the ASPNETDB.MDF database to the App_Data folder.
Question: Can we use CreateUserWizard with custom database with out using ASPNETDB or asp.net membership ?
The CreateUserWizard control provides the user interface for the MembershipProvider object that communicates with your Web site's user data store to create new user accounts in the data store. The CreateUserWizard relies on the MembershipProvider to create the user and disable them if necessary (cf. msdn).
So you have to use a Membership Provider if you use the CreateUserWizard.
If you do not want to use the standard Membership Provider, you should consider creating a Custom Membership Provider.
But from your question it is not clear why you do not want to use the standard Membership. May be it is worth to look at the possibility to include the standard Membership schema into your own database and save yourself a lot of work (not to mention possible security issues etc.) using the authorisation functionality which is already implemented in asp.net. Here you can find how to put the Membership schema into the same database as the application data.
UPDATE:
If you still want to prevent the CreateUserWizard's CreateUser step from creating the user by means of Membership Provider, you can try to handle the CreatingUser event and set its LoginCancelEventArgs.Cancel property to true.
Example code:
protected void RegisterUser_CreatingUser(object sender, LoginCancelEventArgs e)
{
e.Cancel = true;
}
Then in order to move to the next page in the wizard you need to handle NextButtonClick event:
Add e.Cancel = False;
Add CreateUserWizard.ActiveStepIndex = (your next wizard step
index);
After that you will need to create the user manually, e.g. in FinishButtonClick event handler.
Hope it helps.
I have had the same problem that i wanted the membership tables, views and stored procedure to be on my database, so you have to run the following command using the visual studio command prompt and write the following command line:
Aspnet_regsql.exe -W
Please notice that it is a case sensitive then a wizard will appear to allow you create the membership tables, views and stored procedures
Then you will need to update you web.config file to update the connection string that points to the .mdf file by your database connection string.
Related
I am just learning the admin side of this in the Web Site Administration Tool, having set up a new project. I have accessed the security panel at the back end, and created an admin role, which is used to access a view through a controller filter. All standard stuff.
However when I try to log in to the front end with this user, it doesn't exist, and I have to create it afresh.
Alternatively when I create a user at the front end, and try to assign him an admin role at the back end it he also doesn't exist.
Only users created at the back end, exist at the back end and can be assigned roles
There seems to be no connection between front end users and back end users. There appears to be two separate databases one holding front end users and one back end users.
Giving a backend user admin rights doesn't seem to work from the front end.
is there some explanation on how this system work around? I have used google without help.
If you're using a standard asp.net mvc 4 application, then yes. This is to be expected.
The reason is that MVC4 by default users a different membership provider called SimpleMembership, and this provider is not compatible with the ASP.NET Configuration utility. That configuration utility uses the old membership provider, which has entirely different tables.
Your options are:
don't use the web configuration utility. Add users manually, or through a script, or maybe create your own admin pages.
Disable simple membership so that MVC uses the old membership system
do something completely different (don't use membership, use a different provider, create your own provider, etc...)
As for a separate database, yes. If you notice, there is no membership configuration in your web.config. Instead, the ASP.NET Congifuration utility uses the default membership configuration that's defined in your machine.config in c:\windows\microsoft.net\framework[64]\config. the default location is a file located in your project directory under the App_Data directory called aspnet.mdf
EDIT:
More information about the new provider here:
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
Also:
http://geekswithblogs.net/Aligned/archive/2012/08/30/mvc-4-authentication.aspx
We have a production site using ASP.NET built in membership. Now we wan't to extend the tables with some custom properties so we built a custom membership provider using ADO.Net entities.
Everything is working fine, we can create new users and the login controls are also working. We imported every existing user from the aspnet_Membership table into our custom table, and copied the password field into our custom password field in the custom table.
Unfortunately, these existing user cannot login into the system. We found out while debugging the system that the password is not properly decrypted (we're using passwordFormat="Encrypted").
For example:
We have an user with password testing123. When we decrypt the password from the database, it returns 睝렱ꀱ䧥꾖饱testing123
Does anybody have an idea what we're doing wrong here?
EDIT:
I find this answer where is described you should remove the salt (8 bytes) from your password. In that case that is the solution for me, but then I have a problem with new users passwords which are working OK by default.. Is there no other possibility?
I want to know whats the "right" way to setup membership in a new website.
When i have new project i can go to Website/ASP.NET Configuration. There i can setup Forms authentication and manage all users that will be using this page. I can make roles and rules on folders. All of this info are saved into table that will be saved locally in database App_Data/ASPNETDB.MDF. What i'm trying to do is that all this info would be on a host server along with the website but not locally.
What is the best way to connect my website that i made locally to a mssql server that is central. I want to be able to go to the asp.net configuration and manage users but i want the data to be saved in the tables on the mssql server not to the aspnetdb.mdf file.
I have already made the asp.net membership tables on the mssql server by using the aspnet_regsql.exe file.
Update:
Never mind, i found out a way to to this.
Just had to add
<remove name="LocalSqlServer"/>
in <ConnectionStrings> and then my own connection string. Now its working...
There is a line command in the Visual Studio SDK called "aspnet_regsql". It opens a window, and you can use it to set up the ASP.NET membership, roles, and profile support in any SQL Server database.
For most applications, you'll probably end up writing your own membership admin pages. It's not hard, and most of the controls you need are in the toolbox in Visual Studio. Here's the cookbook I've given in presentations on security:
To add ASP.NET membership and roles to an existing SQL Server database:
Open a Visual Studio 2008 command window.
(If you must run SQL line commands in Administrator mode, you will need
to open a command line in administrator mode, then set the path to
include the Visual Studio SDK executables.)
Run aspnet_regsql in that command window.
For the SQL user logins that will use the database, add one or more
of the following membership provider roles:
aspnet_Membership_FullAccess - if users can register themselves or others
aspnet_Membership_BasicAccess - users cannot register themselves
aspnet_Membership_ReportingAccess - for membership statistics
For the SQL user logins, add one or more of the following role provider roles:
aspnet_Roles_FullAccess - create and delete roles
aspnet_Roles_BasicAccess - use asp.net roles
Configure your initial application and roles using SQL Server Management Studio:
exec aspnet_Applications_CreateApplication #ApplicationName='Northwind',#ApplicationID=''
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Employee'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Manager'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Master'
Implement your "New User" page, but don't lock it down with forms authorization yet.
You may want to implement your own form, assuming you have user records already existing
in your database, and assuming that you'd like to add roles as part of the "create user"
process. In any case, use this page to create an initial set of users for ASP.NET
membership; it's easier this way than trying to make it work with stored procedures.
See sample code for an implementation of user creation without using the ASP.NET
LoginView control.
Note that this "Add a User" page in the sample application assumes a number of things
that are hard to do with the standard Login control in ASP.NET. If you're creating users
as an administrative function, rather than letting users add themselves, you probably
want to have multiple roles, and be able to select the role. Even more important,
you may have "user" tables already established in your database, and need to integrate
"new user" functionality with adding records to your application's user table. This is
a prototype for creating your own Login control, collecting additional data and
integrating the creation of user records, ASP.NET membership records, and ASP.NET role
assignments. All of this is done within an ambient transaction, so they either succeed
or fail as a single unit of work.
Once you've created users and added them to roles, you can set up forms authentication
and lock down your pages that require authorization. Notes:
a. Don't require authentication for your top-level directory. Pages at this level
should be publicly accessible.
b. Add a web.config in each subdirectory where pages require authentication.
Usually, setting the authentication level will be the only function in these
web.config files.
i am new to asp.net mvc so please be explicit as possible.
Here is my goal:
i want to create a simple website where users can:
Register and log in
Enter there contact details(phone, address, etc)
View there contact details
Edit details of #3.
Later in the website, i will create other pages that use this data but for now the only items above are needed.
my questions is that i have been reviewing the default asp.net mvc sample that comes when you create a new asp.net mvc app.
I am trying to figure out if i should store all the contact details in the aspnetdb.mdf database in an existing table or i should be creating new tables.
it seems like i could extend aspnet_Users or aspnet_membership.
please let me know if these tables can be extended to store additional fields or if its safer to just create a new table in this database.
You could use an Asp.net profile provider to store the information. Follow the link for instructions on using the built-in SqlProfileProvider. By default, the SqlProfileProvider will create tables in the aspnetdb.mdf file, so you can keep everything in one place. You can access the profile provider as a property on the HttpContext.
Edit: Better link for ASP.Net profile information
Using the Profile provider, you don't have to worry about making database calls or identifying the current user. It's all done on your behalf. Double-check the documentation, because the following might be a little off.
You add the fields that you want in your web.config inside <system.web>. In your case, it would be the necessary contact information.
<profile>
<properties>
<add name="Address" />
<add name="City" />
<add name="State" />
<plus other fields ... />
</properties>
</profile>
Then, you can access HttpContext.Profile.Address and so forth and the provider will take care of tying everything to the current user.
Adding and editing the information means displaying a form. Viewing the details is just displaying all the fields you saved from the previous form post.
The NerdDinner source and tutorial are well worth checking out if you're completely new to MVC.
You may also want to take a look at the SQL Server Publishing Wizard found here.
It essentially allows you to copy the database structure and/or data to a .sql file that you can then import into your primary SQL database.
I don't particularly like the aspnetdb approach but that's my personal opinion.
This question has been the cause of a little bit of an internal debate for me. I can see the logic in extending the existing membership provider to hold the neccessary aditional information, however I would only use the aspnetdb database to store this information if that was the path taken, as the purpose of that database, in my mind, is to store information mamaged by ASP.NET via the Membership API
If you did decide not to extend asp.net's existing membership provider then I would suggest creating another database, or at the very least some new table(s) to keep data you are managing seperate from any other data managed by ASP.NET
I have Membership, Profile and Role providers setup for my .NET MVC website. I would like to say: this Role has access to that Page.
How do I 'inject' this code to the RoleProvider? Or do I have to override it somehow? Any leads?
(Roles are stored in the default ASP.NET SqlRoleProvider, Pages are stored in a seperate SQL database).
Why would you inject this into the role provider? Why not just decorate the ActionResult [Authorise(Roles="myrole")]?
I understand that your pages are in the database but the action result still needs to call the view right?
I guess you could write you're own custom attribute which can check and either grant access or deny it.
I don't think the role provider is the right place for determining whether a page can be displayed or not.
Take a look at using sitemaps under asp.net. It is VERY easy to manage and to extend.
I have even used them as the datasource for a menu system.
Once in your page, you can do something like:
User.IsInRole("RoleName")