Advice needed (ASP.NET membership)

[Robert]

(Sorry: This was accidentally cross-posted to
"microsoft.public.dotnet.languages.csharp")

Hi there,

I''m going be to be working on a new (Internet) web site that requires users
to sign up for the service we offer (with a SQL Server back end). Does it
make sense to rely on the existing SQL Server membership provider to store
our users. That is, should I start by:

1) Creating my DB using the standard "ASPNETDB.mdf" file generated with the
"ASP.NET Configuration" tool (available on the Visual Studio "Website" menu)
2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above DB)

Is this an accepted and even recommended practice. My app would then add new
users to the "aspnet_Users" table when they sign up (using
"Membership.CreateUser()"). It doesn't seem to make sense to create a new DB
from scratch with my own "Users" table. Can someone offer some advice.
Thanks.

 

[sloan]

//2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above DB)//

I hate that idea. Others might disagree.

The Membership database should be thought of in higher regards than just 1
application.
One quick way to discern that nugget:
select * from dbo.aspnet_Applications

That's a legit query (table) in the AspNetMembership database. That does
not sound like "1 application" based to me.


http://weblogs.asp.net/scottgu/archive/2005/08/25/423703.aspx
I would avoid the asp.net configuration tool.
My opinion is that it is made for hobbyists making websites for their local
kids soccer club or something.
It not meant to be a remote administration tool.

In fact, I wrote a rough "helper" script to move dev data to production data
here
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!160.entry


The big question is .. do you have your own (and existing) dbo.User table
right now?

If so you need to consider a Custom Membership Provider.

If not, then you can use the existing SqlMembershipProvider (thats the
default "concrete" version of the MembershipProvider that everyone gets out
of the box).

.................

 

[Eliyahu Goldin]

I thinks a cleaner solution would be to import the ASP.NET Membership tables
into your SQL Server back end. You can do it with the aspnet_regsql.exe tool
found in C:\Windows\Microsoft.NET\Framework\v2.0.50727

Then you can create your own table user_Details extending the standard one.
With this you leave the whole ASP.NET membership datastore intact, without
taking risk of inroducing problems.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin

(Sorry: This was accidentally cross-posted to
"microsoft.public.dotnet.languages.csharp")

Hi there,

I''m going be to be working on a new (Internet) web site that requires
users
to sign up for the service we offer (with a SQL Server back end). Does it
make sense to rely on the existing SQL Server membership provider to store
our users. That is, should I start by:

1) Creating my DB using the standard "ASPNETDB.mdf" file generated with
the
"ASP.NET Configuration" tool (available on the Visual Studio "Website"
menu)
2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above DB)

Is this an accepted and even recommended practice. My app would then add
new
users to the "aspnet_Users" table when they sign up (using
"Membership.CreateUser()"). It doesn't seem to make sense to create a new
DB
from scratch with my own "Users" table. Can someone offer some advice.
Thanks.





__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Robert]

//2) Build the remainder of my DB on top of this one (including adding my

application-specific columns to the "aspnet_Users" table in the above
DB)//

I hate that idea. Others might disagree.

I don't like it either but I'm not sure at this point how to roll this
myself (read on)

http://weblogs.asp.net/scottgu/archive/2005/08/25/423703.aspx
I would avoid the asp.net configuration tool.
My opinion is that it is made for hobbyists making websites for their
local kids soccer club or something.
It not meant to be a remote administration tool.

In fact, I wrote a rough "helper" script to move dev data to production
data here
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!160.entry

Thanks. I'll take at look at this.

The big question is .. do you have your own (and existing) dbo.User table
right now?

No. Starting from scratch.

If so you need to consider a Custom Membership Provider.

If not, then you can use the existing SqlMembershipProvider (thats the
default "concrete" version of the MembershipProvider that everyone gets
out of the box).

Ok, so you're recommendation is to build my own provider? Do I inherit this
from "SqlMembershipProvider" rather than rolling my own and how do I create
my DB in the first place (to give me what "ASPNETDB.mdf" does for free).
I'll research the details if you can just briefly elaborate on these two
points in particuar. Thanks for your help.

 

[Robert]

I thinks a cleaner solution would be to import the ASP.NET Membership

tables into your SQL Server back end. You can do it with the
aspnet_regsql.exe tool found in
C:\Windows\Microsoft.NET\Framework\v2.0.50727

Then you can create your own table user_Details extending the standard
one. With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.

This sounds like a very good idea and I'll look into it. It's unclear to me
what the accepted standard is however (if any). Like many others, I have
customer orders to keep, etc. (for customers who sign up for the service).
Once signed up that is, customers can then log in and place their order(s)
accordingly. The membership facilities of ASP.NET seem like the perfect way
to handle this but how do others deal with it. Do most import the ASP.NET
tables in as you suggested, and then create a "user_Details" table (a child
of the NATIVE "aspnet_Users" table presumbly). You can roll your own
provider of course but then you're reinventing the wheel. So is importing as
you suggested the recommended way of doing things (maybe not officially by
MSFT, I don't know, but what's the accepted protocol here). Thanks.

 

[sloan]

/> Then you can create your own table user_Details extending the standard
one.

With this you leave the whole ASP.NET membership datastore intact, without
taking risk of inroducing problems.
//

Well, I'm not going to 100% agree with that advice.

From http://aspnet.4guysfromrolla.com/articles/101106-1.aspx
//Quote
Rather than add additional user attributes to the Membership system,
Microsoft instead created the Profile system to handle additional user
properties. The Profile system allows the additional, user-specific
properties to be defined in the Web.config file and is responsible for
persisting these values to some data store.
// End Quote

the Profile system is what MS intended to capture these extra nuggets of
information.

I'm not saying that "if you deviate from the MS model , you're deficient".
I'm just pointing it out as the first-attempt option....

If you're going to jump into the MembershipProvider pool, then there are a
couple of players.
MembershipProvider
RoleProvider
Profile

I thinks a cleaner solution would be to import the ASP.NET Membership
tables into your SQL Server back end. You can do it with the
aspnet_regsql.exe tool found in
C:\Windows\Microsoft.NET\Framework\v2.0.50727

Then you can create your own table user_Details extending the standard
one. With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin

(Sorry: This was accidentally cross-posted to
"microsoft.public.dotnet.languages.csharp")

Hi there,

I''m going be to be working on a new (Internet) web site that requires
users
to sign up for the service we offer (with a SQL Server back end). Does it
make sense to rely on the existing SQL Server membership provider to
store
our users. That is, should I start by:

1) Creating my DB using the standard "ASPNETDB.mdf" file generated with
the
"ASP.NET Configuration" tool (available on the Visual Studio "Website"
menu)
2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above DB)

Is this an accepted and even recommended practice. My app would then add
new
users to the "aspnet_Users" table when they sign up (using
"Membership.CreateUser()"). It doesn't seem to make sense to create a new
DB
from scratch with my own "Users" table. Can someone offer some advice.
Thanks.





__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[sloan]

//Ok, so you're recommendation is to build my own provider? //

No, if you already have an existing db schema, then I would recommend a
custom provider.

If you're starting from scratch, then its muddier which one to pick.

I would look at the interface of (actually, members of the abstract class)
and see which ones you're actually going to use:
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider_members.aspx

If you implement your own, then its not super trivial. However, you don't
~have to implement every method (just raise an NotImplementedException) if
you never plan on using the functionality.


...................

It sounds like you're leaning toward the out of the box solution.
Which is OK.

What I would do is ......even if you put those tables in your
database........... DRAW A STRONG MENTAL SEPERATION LINE between the asp_
tables and your application.
Because you may want to "disconnect" and seperate them in the future.

Again, the MembershipProvider is meant to be "higher up" than just 1 single
application.
You may never use it for more than 1 application, but that doesn't mean
marry-it or spaghetti-it all together either.

And again, I would strongly consider:
select * from dbo.aspnet_Applications
what that query means in your design choices.

 

[Eliyahu Goldin]

Here are 2 native tables together with another table I created for adding
more user fields:

CREATE TABLE [dbo].[aspnet_Membership](
[ApplicationId] [uniqueidentifier] NOT NULL,
[UserId] [uniqueidentifier] NOT NULL,
[Password] [nvarchar](128) NOT NULL,
[PasswordFormat] [int] NOT NULL,
[PasswordSalt] [nvarchar](128) NOT NULL,
[MobilePIN] [nvarchar](16) NULL,
[nvarchar](256) NULL,
[LoweredEmail] [nvarchar](256) NULL,
[PasswordQuestion] [nvarchar](256) NULL,
[PasswordAnswer] [nvarchar](128) NULL,
[IsApproved] [bit] NOT NULL,
[IsLockedOut] [bit] NOT NULL,
[CreateDate] [datetime] NOT NULL,
[LastLoginDate] [datetime] NOT NULL,
[LastPasswordChangedDate] [datetime] NOT NULL,
[LastLockoutDate] [datetime] NOT NULL,
[FailedPasswordAttemptCount] [int] NOT NULL,
[FailedPasswordAttemptWindowStart] [datetime] NOT NULL,
[FailedPasswordAnswerAttemptCount] [int] NOT NULL,
[FailedPasswordAnswerAttemptWindowStart] [datetime] NOT NULL,
[Comment] [ntext] NULL)

CREATE TABLE [dbo].[aspnet_Users](
[ApplicationId] [uniqueidentifier] NOT NULL,
[UserId] [uniqueidentifier] NOT NULL,
[UserName] [nvarchar](256) NOT NULL,
[LoweredUserName] [nvarchar](256) NOT NULL,
[MobileAlias] [nvarchar](16) NULL,
[IsAnonymous] [bit] NOT NULL,
[LastActivityDate] [datetime] NOT NULL)

CREATE TABLE [user_Details](
[UserId] [uniqueidentifier] NOT NULL,
[FirstName] [nvarchar](15) NULL,
[LastName] [nvarchar](20) NULL,
[MiddleInitial] [nchar](1) NULL,
[NameSuffix] [nvarchar](15) NULL,
[Title] [nvarchar](10) NULL,
[AddressLine1] [nvarchar](40) NULL,
[AddressLine2] [nvarchar](40) NULL,
[City] [nvarchar](30) NULL,
[State] [nvarchar](2) NULL,
[Zip] [nvarchar](10) NULL,
[HomePhone] [nvarchar](20) NULL,
[CellPhone] [nvarchar](20) NULL,
[OtherPhone] [nvarchar](20) NULL,
[SecondaryEmail] [nvarchar](100) NULL,
[IsDeleted] [bit] NULL)

You can join the tables by [UserId] into a single view.

I recommend this way just because I am using it successfully in my
application. Other developers may have different opinions.

--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin


[QUOTE="Robert"]
This sounds like a very good idea and I'll look into it. It's unclear to
me what the accepted standard is however (if any). Like many others, I
have customer orders to keep, etc. (for customers who sign up for the
service). Once signed up that is, customers can then log in and place
their order(s) accordingly. The membership facilities of ASP.NET seem like
the perfect way to handle this but how do others deal with it. Do most
import the ASP.NET tables in as you suggested, and then create a
"user_Details" table (a child of the NATIVE "aspnet_Users" table
presumbly). You can roll your own provider of course but then you're
reinventing the wheel. So is importing as you suggested the recommended
way of doing things (maybe not officially by MSFT, I don't know, but
what's the accepted protocol here). Thanks.


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
[/QUOTE]


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Robert]

/> Then you can create your own table user_Details extending the standard

one.

Well, I'm not going to 100% agree with that advice.

From http://aspnet.4guysfromrolla.com/articles/101106-1.aspx
//Quote
Rather than add additional user attributes to the Membership system,
Microsoft instead created the Profile system to handle additional user
properties. The Profile system allows the additional, user-specific
properties to be defined in the Web.config file and is responsible for
persisting these values to some data store.
// End Quote

the Profile system is what MS intended to capture these extra nuggets of
information.

I'm not saying that "if you deviate from the MS model , you're deficient".
I'm just pointing it out as the first-attempt option....

If you're going to jump into the MembershipProvider pool, then there are a
couple of players.
MembershipProvider
RoleProvider
Profile

I'll take all this under advisement (including your last post further up the
thread - thanks). I have more research to do of course but I don't want to
introduce a hack either (or a technique most would find unacceptable). Many
people must encounter the situation however so I'm not sure what "most" do.
Is there a mainstream technique for dealing with this which is what I'm
trying to establish. Thanks for both your help.

 

[Robert]

Thank you. This does appear to be acceptable then and I'll explore it along
with the other ideas mentioned. Everyone's assistance has been greatly
apprecated.

 

[sloan]

Here is a consolidated site explaining most (if not all) of the options:
http://aspnet.4guysfromrolla.com/articles/120705-1.aspx


Good luck.

 

[Eliyahu Goldin]

The out-of-box profile provider is good only for using in the application
code. You can't use it in any database queries.

CREATE TABLE [dbo].[aspnet_Profile](
[UserId] [uniqueidentifier] NOT NULL,
[PropertyNames] [ntext] NOT NULL,
[PropertyValuesString] [ntext] NOT NULL,
[PropertyValuesBinary] [image] NOT NULL,
[LastUpdatedDate] [datetime] NOT NULL)

When you write Profile.PostalCode in the code, it is fine. But how do you
get to the same [PostalCode] in sql?

This rendered the whole idea unusable for me.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin

/> Then you can create your own table user_Details extending the standard
one.

With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.
//

Well, I'm not going to 100% agree with that advice.

From http://aspnet.4guysfromrolla.com/articles/101106-1.aspx
//Quote
Rather than add additional user attributes to the Membership system,
Microsoft instead created the Profile system to handle additional user
properties. The Profile system allows the additional, user-specific
properties to be defined in the Web.config file and is responsible for
persisting these values to some data store.
// End Quote

the Profile system is what MS intended to capture these extra nuggets of
information.

I'm not saying that "if you deviate from the MS model , you're deficient".
I'm just pointing it out as the first-attempt option....

If you're going to jump into the MembershipProvider pool, then there are a
couple of players.
MembershipProvider
RoleProvider
Profile

I thinks a cleaner solution would be to import the ASP.NET Membership
tables into your SQL Server back end. You can do it with the
aspnet_regsql.exe tool found in
C:\Windows\Microsoft.NET\Framework\v2.0.50727

Then you can create your own table user_Details extending the standard
one. With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin

(Sorry: This was accidentally cross-posted to
"microsoft.public.dotnet.languages.csharp")

Hi there,

I''m going be to be working on a new (Internet) web site that requires
users
to sign up for the service we offer (with a SQL Server back end). Does
it
make sense to rely on the existing SQL Server membership provider to
store
our users. That is, should I start by:

1) Creating my DB using the standard "ASPNETDB.mdf" file generated with
the
"ASP.NET Configuration" tool (available on the Visual Studio "Website"
menu)
2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above
DB)

Is this an accepted and even recommended practice. My app would then add
new
users to the "aspnet_Users" table when they sign up (using
"Membership.CreateUser()"). It doesn't seem to make sense to create a
new DB
from scratch with my own "Users" table. Can someone offer some advice.
Thanks.





__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Robert]

Here is a consolidated site explaining most (if not all) of the options:

http://aspnet.4guysfromrolla.com/articles/120705-1.aspx

Thanks for all your help. Appreciated.

 

[Robert]

Thanks for that.

 

[sloan]

I agree it does not work in every area.

The "dynamic property"'ness of the implementation is a double edged sword.

This is why I wrote "Well, I'm not going to 100% agree with that advice."
Aka, there is a part of me that knows it won't work in all areas.
Aka, there is a certain % which agrees with what you wrote.

It definately has some challenges.

And I too also have some user-detail information that I have to query
against.
And the profile system didn't work out.

The out-of-box profile provider is good only for using in the application
code. You can't use it in any database queries.

CREATE TABLE [dbo].[aspnet_Profile](
[UserId] [uniqueidentifier] NOT NULL,
[PropertyNames] [ntext] NOT NULL,
[PropertyValuesString] [ntext] NOT NULL,
[PropertyValuesBinary] [image] NOT NULL,
[LastUpdatedDate] [datetime] NOT NULL)

When you write Profile.PostalCode in the code, it is fine. But how do you
get to the same [PostalCode] in sql?

This rendered the whole idea unusable for me.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin

/> Then you can create your own table user_Details extending the standard
one.

With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.
//

Well, I'm not going to 100% agree with that advice.

From http://aspnet.4guysfromrolla.com/articles/101106-1.aspx
//Quote
Rather than add additional user attributes to the Membership system,
Microsoft instead created the Profile system to handle additional user
properties. The Profile system allows the additional, user-specific
properties to be defined in the Web.config file and is responsible for
persisting these values to some data store.
// End Quote

the Profile system is what MS intended to capture these extra nuggets of
information.

I'm not saying that "if you deviate from the MS model , you're
deficient". I'm just pointing it out as the first-attempt option....

If you're going to jump into the MembershipProvider pool, then there are
a couple of players.
MembershipProvider
RoleProvider
Profile

I thinks a cleaner solution would be to import the ASP.NET Membership
tables into your SQL Server back end. You can do it with the
aspnet_regsql.exe tool found in
C:\Windows\Microsoft.NET\Framework\v2.0.50727

Then you can create your own table user_Details extending the standard
one. With this you leave the whole ASP.NET membership datastore intact,
without taking risk of inroducing problems.


--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin


(Sorry: This was accidentally cross-posted to
"microsoft.public.dotnet.languages.csharp")

Hi there,

I''m going be to be working on a new (Internet) web site that requires
users
to sign up for the service we offer (with a SQL Server back end). Does
it
make sense to rely on the existing SQL Server membership provider to
store
our users. That is, should I start by:

1) Creating my DB using the standard "ASPNETDB.mdf" file generated with
the
"ASP.NET Configuration" tool (available on the Visual Studio "Website"
menu)
2) Build the remainder of my DB on top of this one (including adding my
application-specific columns to the "aspnet_Users" table in the above
DB)

Is this an accepted and even recommended practice. My app would then
add new
users to the "aspnet_Users" table when they sign up (using
"Membership.CreateUser()"). It doesn't seem to make sense to create a
new DB
from scratch with my own "Users" table. Can someone offer some advice.
Thanks.





__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4239 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com