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
Related
I have an ASP.NET MVC 5 application where I want to authorize users to access specific content via roles. These roles will be passed in through the application headers. After exploring ASP.NET membership, it seems like the membership information is normally supposed to be stored in a table, but I do not need/want this. I simply need to take the role from the header when the user accesses the application, and then access it later (ideally) using ASP.NET membership to use data annotations in my models and/or views to control who can see what information.
I apologize if this is sort of ambiguous, I am just not sure where to start since I cannot seem to find an example of someone simply taking the role from the headers without storing this information in a membership table.
Thanks!
I'm using aspnet memberhips database for authorization and authentication for my azure web application.
This aspnet application contains the employees details. All good until we got new requirment. The new requirement is to in include lots of extra attributes related to employees such as awardcode, costcentre, division, location etc...
The requirement is also to admin these details via Admin portal.
Is there any way we can fit the above requirement with in aspnet database? Should I add extra tables and fields or there's a better way of acheving this.
Thank you.
You might want to consider the ASP.NET Profile provider. It's another component of the Membership framework. It stores a somewhat dynamic list of user properties in the database, typically in the aspnet_Profile table. You can get a lot of functionality for free by making additions to Web.config, or you can customize heavily by implementing a custom profile provider. Here are some links to get started:
http://msdn.microsoft.com/en-us/library/014bec1k.aspx
http://msdn.microsoft.com/en-us/magazine/cc163457.aspx
There have been times though when this approach wasn't a great fit for me, so I simply created a separate UserRecord table in the database with exactly the columns I wanted, and added some views to the database that joined UserRecord with the bulitin aspnet_Membership table, etc., to get the right combination of data.
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.
Currently using DNN 5.2.x and we are using only 1 portal on the site. We need to make a mobile version of the portal and eliminate most of the extra DNN stuff as info will be just displayed. So what we decided to do was create seperate ASP.NET Web Forms website and utilize the DNN providers (membership, roles, etc) to do the logging in. However we are currently having issues. The one in particular is ("unknown exception trying to write to log"). We've moved most of the DNN Global.asax (i.e. SimpleContainer instructions) file to the new website and added the necessary web.config sections and references however we get this error when a user logs in. We did copy over the same web.config machine key to the new website. The connection strings are also there (app settings and connection string sections and is named SiteSqlServer).
So my question is, has anyone created a new website around DNN without using DNN except for the membership? i.e. no modules, no skins, etc. Just validate user and get roles.
If you have what needs to be done to get DNN 5.2.x (or later) to log a user in and return the roles, could you post your steps?
The default DNN login is based on ASP.NET membership. If all you really want is the login feature, it will be MUCH MUCH easier to simply use the ASP.NET membership directly than try to rip it out of DNN.
What you are trying is not impossible, but certainly will require substantial patience with trial and error.
For only validation users and getting roles you could write your own simple providers that utilize dnn special tables in the databse like (Users, Roles, UserRoles, Profile etc). The table User is associated with the aspnet_Membership and aspnet_Users standard tables via the Username field.
There are many options which are open for you.
If you really don't want to digg into complecations of how to integrate the dnn membership and role provider will work, you can check dnn single sign on
Another option is to have your webforms application as a subfolder in your dnn website. that way you don't have to do much effort and you will have all the good things ready to get started. even you can directly convert your skin to master page and reuse almost all the css and image related suff
In addition to above, I also suggest another smart way to do this. Since you are considering a mobile site, why don't you try and detect the browser using Request.Browser and create a separate skin for dnn that is of smaller size. We can easily switch skins dynamically for service requests.
I hope this will help. If you have more questions regarding this, I will be happy to help. Just drop me and email and I will try to help you get as close as possible to get you going.
Good Luck
This is the route we took. We basically implemented DNN in the mobile version of the website. Except we only utilized the User Membership features of DNN. To do this we had to use all the same core DNN dll's and also include all the "bootup" features in the global.asax file. We also had to on every request inject a UserInfo object into the session context. I forget the key name for the UserInfo oject used but it is used by DNN and must be set in a DNN handler that we did not incorporate. Other than that it works perfectly. We have the ability to get all the roles a user is in and etc.
In asp.net Webforms apps, is there not any kind of maintenance UI page to edit and maintain the Profile properties of a User (I'm using VS2008 and the Web Application template), like in the WSAT Web Site Administratration Tool where you already can edit the basic Membership and Role properties for a User? I'm using the basic SQL Express data tables and the basic Membership and Role providers, and now I want to begin using the Profile provider to store and access additional properties for each User I create an account for. For instance, when I create a new User and assign them to a Role(s) on my web app, I use the WSAT tool, and now I also need to set certain Profile properties for them too. Is the only way to set these properties is programmatically? Surely there is an Admininstrative type of UI page for this so you can quickly view and edit Profile properties for a User.
Roles and Membership conform to a standard schema that you can easily create a static form for editing. Profile details are dynamic based on your configuration settings - and building dynamic forms can be a bit tricky.
On top of that, the default Profile provider stores all the profile information in one concatenated field, so you'd end up with a list of comma-separated values if they went for a really basic form.