Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / General / November 2007

Tip: Looking for answers? Try searching our database.

I feel it makes sense NOT to use custom membership & role providers

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
alexandis@gmail.com - 07 Nov 2007 16:54 GMT
We have tables of logins (users), that differs much from standard
microsoft structure - we don't use control question/answer, date
fields, etc. But instead we have several additional fields.

I expanded membership class and it works for logging in, but going
further - creating user - I must make following in CreateUserWizard
template:

1) create 'users' record filling standard microsoft fields and ignore
those I don't use (mentioned above), i.e. put nulls, "", mindate,
etc...
2) update this record, initializing it with MY fields

So, one db operation operation is splitted. It looks ugly...

Concerning role provider: they offer user2role with userName and
roleName fields! But in this case I don't have relationship between
tables, because userName is not a primary key in users table (ID is,
but ID is integer).

I've decided to make custom login control and NOT to use custom
membership provider and role provider.

I ~hope~ it's correct decision. But I'd like to hear objections, until
it's too late :) and good article about further process... maybe there
is one from the person who took the same decision. Is there much work
to go without standard login control and provider? Would it be good to
have classes similar to the one I've already made as custom providers?
Maybe I could just change them and adopt for use as NOT provider-
classes?
Peter Bromberg [C# MVP] - 07 Nov 2007 19:04 GMT
Whatever "floats your boat". Sometimes if you already have a custom setup
that doesn't lend well to the existing providers, it may be better to roll
your own.
-- Peter
http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder:    http://www.blogmetafinder.com

> We have tables of logins (users), that differs much from standard
> microsoft structure - we don't use control question/answer, date
[quoted text clipped - 26 lines]
> Maybe I could just change them and adopt for use as NOT provider-
> classes?
alexandis@gmail.com - 09 Nov 2007 13:30 GMT
Writing custom provider from scratch is not a trivia, so I'd like to
show my thoughts, maybe I'm wrong somewhere?

Let's say, we have 'users' table, that contains obligatory fields not
represented in 'microsoft users table'.

Splitting such info into 2 tables (1:1) won't go, because it's
impossible (as far as i can see) to implement transaction for filling
these 2 tables ('CreateUser' method call is hidden) and all in all -
such structure looks clumsy...

Maybe theoretically it's possible to create additional corresponding
fields in custom membership provider class and initialize them in
'CreatingUser' method, then take them for inserting new record in
'CreateUser'? But such approach also looks ugly... :(

Creating own membership provider from scratch is a headache,
especially for beginners (you have to deal with multithreading,
preventing access to membership while initialize method works).

I wonder why Microsoft just hadn't created one more abstraction layer
for the structure of 'users' table? So instead of having
'CreateUser(param1, param2, ... paramN)' we could have something like
'CreateUser(UserStruct user)'....
alexandis@gmail.com - 09 Nov 2007 13:36 GMT
I've met similar discussion about all this:

http://groups.google.com.ua/group/microsoft.public.dotnet.framework.aspnet/brows
e_thread/thread/87a639a5779b236/37faf3ad1c4434ad?hl=uk&lnk=gst&q=membership+prov
ider#37faf3ad1c4434ad


and met interesting idea about using providerUserKey field :)

Maybe someone offer another approaches also?

Please, don't offer 'profile' stuff again.
darrel - 09 Nov 2007 15:35 GMT
> I wonder why Microsoft just hadn't created one more abstraction layer
> for the structure of 'users' table?

Like many of their products, they simply don't have to. They make things
'good enough to sell' but not necessarily 'good enough to use in a pragmatic
fashion'.

I think the membership provider thing is a great idea. I still don't get it.
Mainly because there's some fundamental concepts that I just haven't found a
comprehensive description of yet.

For now, I've reverted back to my own login system (which, admittedly, for
most of my sites, is all I really need) but hope to fight the Membership
Provider again some long weekend when I have nothing else to do.

-Darrel
alexandis@gmail.com - 14 Nov 2007 14:18 GMT
:)

I decided to stick to provider, the only problem was 'providerUserKey'
- i still can't see elegant way to assign value to it

I wonder - why Microsoft put it as INPUT parameter into CreateUser
method with NO WAY to initialize it manually

So i see 2 ways:
1) easier, but not elegant at all - create session variable and use it
to keep extrafield info: initialize it in CreatingUser and read it
inside CreateUser - so providerUserKey parameter is just left
behind...
2) to make extra property for keeping these extra fields in extended
membershipprovider class. Since this class is a singletone, it should
keep a LIST of objects, where every list item corresponds to specific
userid (login id). So, we assign extrafield info to such object in
CreatingUser and read it inside CreateUser: the same idea as in method
1

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.