ASP.NET 2: Membership/RoleMangement vs. ASP.NET 1.1.. question

[matt]

hello,

im working on my first public-facing ASP.NET 2 website, and i have a
question/concern about authentication integration.

in ASP.NET 1.1, one would typically go w/ a "role yer own"
webforms/database role-based model: in your db youd have a Users table,
a RoleGroups table, a UserRoles table (see
http://aspnet.4guysfromrolla.com/articles/082703-1.aspx).

this worked well, because it hooked in directly with your typical Users
table (UserID, UserName, Email, FirstName, LastName, etc...)

in ASP.NET 2.0, one has the built-in Membership stuff, which uses its
own SQL Server/Access database (the "ASPNETDB" datasource). and via
Visual Studio 2005's "ASP.NET Configuration" GUI, one has many useful
user/group management tools (add/delete role, find user, etc..!).

however...i still need my custom db's User table -- as is expected,
there are many columns i have for my users that are not in the
MembershipUser object.

herein lies the problem -- if i am to use ASP.NET 2's Authentication
and RoleManagement funcationality (database), i am in effect
maintaining *two* databases of users! the authentication db
("ASPNETDB"), and my customer db. this starts to add complication, not
to mention data duplication. for example, if i wish to delete a user
altogether, i must now delete the user in two different databases.
likewise, if i wish to add a user, i have to add him in two databases
-- and if these tasks fail for some reason in one but not the other, it
seems quite messy.

another big concern is, most of my 1.1 apps use a simple Int32 "UserID"
identified column for anything related to my users -- relationships to
orders, comments/feedback, etc.. ASPNETDB has a UserID property, but i
cant seem to retrieve it via the MemberUser obj. and it doesnt look
like a simple indentifier int, either.

so, what is the consenus, here? how best to work w/ this model shift
between 1.1 and 2.0? how does one link their custom business-rules User
table to the authentication User table...!?


thanks,
matt

 

[Juan T. Llibre]

Read this article :
http://www.devx.com/asp/Article/29256
"Writing A Custom Membership Provider for your ASP.NET 2.0 Web Site"

Then, download the code sample there, and modify it to suit your needs.

 

[Guest]

For the data type in the database the userID field is a unique identifier.
This is a totally unique hex number. They use this so that you can have a
crap load of users.

On your other issue with the way the table is set up, here is what I did.

I had asp.net 2.0 set up the membership tables in my database, then I just
added to that table any additional fields that I wanted. This made it so
that all the membership stuff works fine and I can have my additional
information in the same table. Either that or reference the userID unique
identifier to another table and you can add whatever you want as well.

J

 

[matt]

Read this article :
Then, download the code sample there, and modify it to suit your needs.

.....wow. this may be my initial reaction, but... it just seems like a
big project -- i have to write custom implementation for so many
methods in that base class... which means also writing my own stored
procs for all that functionality.

im just wondering if i shouldnt try to keep the 1.1 system i have...
granted it doesnt have all the pretty password functions, but it would
only take an hour or two for me to migrate it to 2.0...


thanks,
matt

 

[matt]

I had asp.net 2.0 set up the membership tables in my database, then I just

added to that table any additional fields that I wanted.

that sounds interesting. so no need to re-write an entire provider? how
did you set this up?

what then, do you use as a good primary key or indentifier for your
user rows -- the MS UserID (hex)? my site uses a lot of user links, im
trying to keep the URLs short (the MS UserID is quite long..i dont need
8 billion users, Int32 worked fine...)


thanks!
matt

 

[Erik Funkenbusch]

however...i still need my custom db's User table -- as is expected,
there are many columns i have for my users that are not in the
MembershipUser object.

You don't need a users table per se, you just need an extended user table.
I'd recommend against extending the ASP.NET table itself, since future
updates might conflict. Instead, create a secondary table that has a
primary key that has a value of uniqueidentifier and link the tables on the
ASP.NET user id.

This approach will require you to create some custom user management pages,
and you'll have to extend the user creation procedure to add your own pages
to capture the information you want or need. You're not maintaining two
tables with the same info, since you're not putting anything in your
extended table that's already in the users table.

If you don't like the uniqueidentifier, you can also add an integer
autonumber field to your extended table that you can use to simplify your
legacy code conversion. Use that autonumber in place of your old user id.

This has the downside of requiring an extra lookup though (unless you store
the integer in a session variable or something) since you now have to
lookup the old userid from the asp.net one.

 

[matt]

This has the downside of requiring an extra lookup though (unless you store

the integer in a session variable or something)

the customer's userID is typically store on our sites as a cookie, once
they are logged in.