A1.) The default SqlMembershipPr ovider is declared in machine.config. We
over-ride the default by declaration in web.config located in the root of
the application. Then we wire up a connection string and poof! It starts
working.
A2.) The same applies to using Profiles for persistant storage of user data
such as a jurisdiction. Profiles are implemented through Membership. The
method data is stored by default in aspnet_Profiles is not query friendly.
You're advised to study the Table Profile Provider which I've just learned
about myself.
A3.) We can create and assign a role such as A-1.0.2 and take each character
apart for introspection and applied semantics. If that's what you mean by
"attributes " applied to a role that is how I would think -- as if the name
of a role is structured like an alphanumeric part number -- but only if I
needed to forget to keep it simple stupid.
Don't fret about writing your own providers. Most of what you need to do is
read more like Juan suggested noting Gus blog contains a compendium of
related URL resources.
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee. com
URL
http://www.metromilwaukee.com/clintongallagher/
"Demetri" <De*****@discus sions.microsoft .com> wrote in message
news:51******** *************** ***********@mic rosoft.com...
I have several questions regarding the Membership and Roles mechanism in
ASP.Net 2.0.
1. In the box, it comes with SqlMembershipPr ovider, which uses SQL Express
2005. What if I want it to use SQL Server 2005 Enterprise (not express)
instead? I'm really hoping I don't have to write my own MembershipProvi der
to
accomplish this.
2. My users have more information about them than the in the box data. For
example, I will need to know what jurisdiction a user belongs to, and of
course when they register they will pick from a list. There is much more
than
that I need to store about my users that will affect their access to
certain
resources (pages), etc. Gawd, I hope I don't have to write my own
MembershipProvi der.
3. My last question is related to roles. I will need more information
about
roles than is provided in the box. For example, a role may have to tell my
application to behave differently depending on some attribute of the role.
Jeeze, I hope I don't have to write my own MembershipProvi der!
So can I do all these modifications with the "in the box" features?
--
-Demetri
