views:

44

answers:

3

I add the Property "WebSite" as a property of a registered user.

<profile>
     <providers>
          <clear/>
          <add name="AspNetSqlProfileProvider" connectionStringName="LocalSqlServer" applicationName="membershipSampleApp" type="System.Web.Profile.SqlProfileProvider"/>
     </providers>
     <properties>
         <add name="Website"/>
     </properties>
</profile>

Where is that custom property stored in the ASPNETDB database and can I query it to, for example, find all of the users that share the same value of a custom property?

If I want this sort of capability, would I be better off to augment the USERS table with my own parallel table and join the two on UserName as the key?

+1  A: 

Yes, you can extend Membership. Here's a long article that explains how to do it. In a nutshell,

The idea behind extending the Membership API is as follows: I’ll create a new ExtendedMembershipUser class that inherits all the default properties from the MembershipUser, and then I’ll add my own custom properties...

For storing the values in the database, it describes a:

table I added to hold the values of the custom properties and the accompanying stored procedures that the new ExtendedMembershipProvider uses.

DOK
+1  A: 

I'm not sure how you're using the "Website" property of the profile but if you have multiple websites using the same Membership store you'd be better off specifying different application names for each site, this was how multiple webs could use the same membership store.

If "Website" is just a property for the user by all means store it in the profile. It doesn't really warrant a rewrite of the membership provider.

Also, the "Website" property would be stored in the aspnet_Profiles table (as binary and XML), this can be difficult to query though. It might make more sense to have a custom profile provider that stores the properties in plain SQL format.

Simon Hazelton
@Simon: Except for the fact that specifying and switching the application name on every request may not be trivial. Otherwise, I completely agree.
Esteban Araya
Hmm, in a multi application environment, you just have to specify a different name for the application property of the provider and it pretty much works automagically :)
Simon Hazelton
A: 

The default profiles implementation sacrifices discoverability for ease of use and flexibility.

If you would like to add indexable and queryable meta data to a user, I would recommend against extending the membership provider as that is not what they are for.

An excellent and easily implemented solution is to use a table based profile provider.

see http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

Sky Sanders