I'm looking into Asp.net Membership Providership Sql to determine if it fits my needs and have a few basic questions.
It seems to create a lot of tables, many of them I don't think I need. I only need one application and no role management. Can I remove the unused tables or should I just leave them alone?
I need another table where I can associate records with the users created with the Sql membership provider. Is it safe to use the "Membership.GetUser.ProviderUserKey.ToString()" as the primary key for this user. I guess so, but it feels a bit like I'm depending on something that's out of my control since it's Asp.Net that manage it.
Also I'm going to access the database directly, without logging in with a user to get statistics. Is it safe to make Sql queries against the database using the aspnet_Users.UserId (table.field).
I guess what I'm afraid of is that suddenly after an framework update, Asp.Net changes the table layout or something.
Obviously, you can do whatever you want to it once you've generated the tables, but I think you should consider the ramifications of that. The Membership Provider framework works very well and is widely implemented. If you use their implementation, just use it and use the pieces you want and leave the rest alone.
They will be very careful when/if they make changes to it to either tell us of the breaking changes or not make any breaking changes.
The framework allows for you to override many of the provided methods, or you can simply write you own custom provider and base it heavily on the out of the box implementation.
ProviderUserKey is meant to store anything you would need to reference, so you can store a key to a record in your own database to store additional user information. I think it's OK to delete unrelated tables, as long as the features you use don't touch it.
I know it touches aspnet_applications, aspnet_users...
As a last resort, you can always create your own custom membership provider by creating a class that inherits from MembershipProvider.
Related
We have a requirement to allow customising our core product and adding additional fields on a per client basis e.g. People entity some client wants to record their favourite colour etc. As far as I know we can't add properties to EF at runtime as it needs classes defined at startup. Each customer has their own database but we are deploying the same solution to all customers with all additional code. We are then detecting which customer they are and running customer specific services etc.
Now the last thing I want is to be forking my project or alternatively adding all fields for all clients. This would seem likely to become a nightmare. Also more often than not the extra fields would only be required in a very limited amount of place. Maybe some reports, couple of screens etc.
I found this article from Jermey Miller http://codebetter.com/jeremymiller/2010/02/16/our-extension-properties-story/ describing how they are adding extension properties and having them go from domain to the web front end.
Has anyone else implemented anything similar using EF? How did it work out? Are there any blogs/samples that anyone has seen? I am not sure if I am searching for the right thing even if someone could tell me the generic name for what we want to do that would help. I'm guessing it is a problem that comes up for other people.
Linked question still requires some forking or implementing all possible extensions in single solution because you are still creating strongly typed extensions upfront (= you know upfront what extensions customer wants). It is not generally extensible solution. If you want generic extensible solution you must leave strongly typed world and describe extensions as data.
You will need to use some metamodel. Your entity classes will contain only properties used by all customers and navigation property to special extension entity (additional table per every extensible entity) where you will be able to put additional properties as name / value pair (you can add other columns like type, validation, etc. if needed).
This will in general moves part of your model from hardcoded scenario to configuration based scenario and your customers will even be allowed to define extensions at runtime (if you implement such feature).
I am currently developing an web site using asp and have a few questions regarding Membership Provider.
I am currently inheriting from Membership Provider class and have just got over the issue of only certain parameters being able to be passed to the CreateUser method.
I have been able to overcome this issue by creating a class that inherits from MembershipUser adding custom properties and then passing that the the UpdateUser method. However to me this seems quite messy and not very efficient as I am making two calls to the database when I could do it in one if I dont use the CreateUserWizard.
So my question is, is using the Provided Login components worthwhile if you are overriding the methods and require more parameters ect in order to keep the use of the properties you can define for this class in the web.config file or is it easier in the long run to just start from scratch. Basically what I want to know is how people have found using Membership by overriding and inheritance over starting from scratch, and how these compare.
Any webpages that talk about this would be good and apologies if the question doesn't make sense or I have missed anything out.
Thanks,
Ric
If I am understanding your question correctly, then yes the membership provider is a great api to build off of so you don't have to reinvent the wheel for the basics of authentication/authorization.
You are using Membership wrong. You should only create your own custom provider when you need to map onto an existing database. IF you are making your own database, then you should just use the default implementation.
Even if you create a custom implementation, you should not do anything that the current membership doesn't already provide. Just map those functions on to your database.
To add additional information, you create a secondary table called UserData or something. This table will be keyed by the MembershipUser.ProviderUserKey, so you lookup any data you need from the other table using the userid from the membership class.
You're really fighting upstream trying to change membership to give you custom things. You can do it, but why cause yourself trouble?
In an ASP.NET application, we'd like to use the SqlWebEventProvider to log any Event that occurs during the application lifetime.
The problem is that we think that the table aspnet_WebEvent_Event doesn't provide enough columns and should log more information (we need to keep the Logged user).
I'm aware that this information could be stored in the "Details" column but it wouldn't then be really simple to filter the results and build reports.
So I'm searching for a simple solution to add a column. I wish I could derive SqlWebEventProvider but the methods used to build the stored procedure parameters are private (PrepareParams() and FillParams()).
Any simple solution that doesn't imply to rewrite the entire Provider class ?
Instead of adding columns to the SqlWebEventProvider and it's table default schema, you may consider creating your own WebEventProvider that logs events to a database of your own schema.
Here is an introductory reference on how to do so.
http://bit.ly/2fXeuH
After a lot of searching it seems that it is not possible without inheriting from the existing SqlWebEventProvider and overriding the methods properly to insert the values.
You can look into the .NET Framework code to check for the current implementation with .Net Reflector
Is it a bad idea (and if why?) to add a a column to the auto generated asp.net (ASPNETDB.MDF, visual studio 2008, mvc framework) "user roles - database"?
(E.g I want to add the columns RealName and LastName to the aspnet_Users table in the database.)
The reason I want to add a column instead of creating an entire new table is to avoid the doule maintenance issue and unnecessary redundancy
There are two generation schemes that are used (from Pragmatic Programmer):
Those that are used once to generate code
Those that are used all the time to have some code synced
The ones that are used for syncing, the results should not be modified, since they could be overridden at a later date when the generation gets done again.
In the case of your generated asp.net database, there is no reason for you to rerun the generation, so it would be OK to edit it.
The only scenario under which you would rerun the generation of the db is if microsoft releases a new version of the users database and you want to use the new one (in this case you might have to edit some parts of your application, so you could readd those two fields), or if you want to regenerate the database with different options. Both of these happen if you are not happy with your current db.
In my opinion that autogenerated database should be replaced by a normal table in application database or at least there should be an official solution to this problem.
I heard that this is quite good solution: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/
why dont you create a new table with a Foriegn Key restraint? It seems like a bad idea to add a column to the aspnetdb...it will be a nightmare if you ever need to recreate your db...
First, those tables aren't really anything specific to MVC: they're created by/for the default AspNetSqlMembershipProvider. (Also applies to other kinds of ASP.NET applications.)
You could probably add new columns safely, but the membership provider wouldn't "see" them. It does provide its profile mechanism to store extra information (which gets serialized, and stored in the aspnet_Profiles table).
If you need to store lots of additional information about the user, you might also check out this sample membership provider that stores profile information in first-class tables, rather that in profile blobs.
I am looking for guidance regarding the best practice around the use of the Profile feature in ASP.NET.
How do you decide what should be kept in the built-in user Profile, or if you should create your own database table and add a column for the desired fields? For example, a user has a zip code, should I save the zip code in my own table, or should I add it to the web.config xml profile and access it via the user profile ASP.NET mechanism?
The pros/cons I can think of right now are that since I don't know the profile very well (it is a bit of a Matrix right now), I probably can do whatever I want if I go the table route (e.g., SQL to get all the users in the same zip code as the current user). I don't know if I can do the same if I use the ASP.NET profile.
Ive only built 2 applications that used the profile provider. Since then I have stayed away from using it. For both of the apps I used it to store information about the user such as their company name, address and phone number.
This worked fine until our client wanted to be able to find a user by one of these fields.
Searching involved looping through every users profile and comparing the information to the search criteria. As the user base grew the search time became unacceptable to our client. The only solution was to create a table to store the users information. Search speed was increased immensely.
I would recommend storing this type of information in its own table.
user profile is a nice clean framework for individual customization(AKA. Profile Properties). (e.g. iGoogle)
the problem of it is its not designed for query and not ideal for data sharing to public user.(you still would be able to do it, with low performance)
so, if you want to enhance the customized user experience, user profile would be a good way to go. otherwise, use your own class and table would be a much better solution.
In my experience its best to keep an the info in the profile to a bare minimum, only put the essentials in there that are directly needed for authentication. Other information such as addresses should be saved in your own database by your own application logic, this approach is more extensible and maintainable.
I think that depends on how many fields you need. To my knowledge, Profiles are essentially a long string that gets split at the given field sizes, which means that they do not scale very well if you have many fields and users.
On the other hand, they are built in, so it's an easy and standardized way, which means there is not a big learning curve and you can use it in future apps as well without needing to tweak it to a new table structure.
Rolling your own thing allows you to put it in a properly normalized database, which drastically improves performance, but you have to write pretty much all the profile managing code yourself.
Edit: Also, Profiles are not cached, so every access to a profile goes to the database first (it's then cached for that request, but the next request will get it from the database again)
If you're thinking about writing your own thing, maybe a custom Profile Provider gives you the best of both worlds - seamless integration, yet the custom stuff you want to do.
I think it is better off using it for supplementary data that is not critical to the user that is only normally important when that user is logging in anyway. Think data that would not break anything important if it was all wiped.
of course thats personal preference but others have raised some other important issues.
Also very useful considering it can be used for an unauthenticated user whose profile is maintained with an anonymous cookie.