Membership Services and Client Logins?

[dm3281]

Hello --

I need to write an ASP.NET 2.0 application for our clients to use to login
and verify file transmissions. Each client will need their own logon, in
addition to a way to assign each user a unique customerid. All users
beloning to the same custeromid would see the same information on the
website.

Can I easily do this using membership services or must I use a combination
of membership services and profiles?

For example.

User: jdoe belongs to customerid 1
User: mbrown belongs to customer id 1
User: jlorsong belongs to customer id 2
User: troberts belongs to customer id 3

In this case, when either jdoe or mbrown login, they would see the same
information on the website. If jlorsong logs in, he would see only his
information.

Thanks

 

[Cowboy \(Gregory A. Beamer\)]

The Membership bits are primarily authentication, not authorization. You can
take care of authorization with roles.

With what you are stating, you might be better extending the Membership bits
with a custom provider, to segregate customer data so it can work with
multiple user accounts. Add an account table, for example, and create an
account for the first user to sign up under customer X. You then have to
alter the sign up procedure or create an admin page for the customer to add
log ins. This is not all handled by any of the bits in Membership.

Personally, I would not go towards profiles. They are okay for
personalization, but do not make a good authorization piece.

 

[clintonG]

Wait a minute. Where could custom providers be implied by the question and
given example? Not needed IMO.

Sure roles --are-- useful here. As I read it the presumed context of some
customerid functions as some role users can be assigned to. And only then
due to the lack of also knowing how the page and sections of the page itself
can be configured with templates to enable or disable display or access to
content and controls on the page based on a role a member has been assigned
to; silver, gold and platinum for example to use some cheesy examples.

The Profile Table provider released after everybody realized how FUBAR
Profiles were implemented once 2.0 was released is much better storing
properties and other meta data for each user; street address, telephone
numbers and so on --but-- while the Table Provider is a big improvement it
does not support the relational model or normalization.

Given what we were told I think Membership and Roles will be just fine
without the need for custom providers.

 

[dm3281]

Thanks for the post.

I was thinking I would just need to create a role for each client that I
have. i.e, "Cust100", "Cust101", "Cust102", "Custom103", etc.

After users have registered, I could then go in and assign what role they
belong to.

I was thinking once they login, the page can then use GetRolesForUser()
method to return the role they belong to. Since I need to the whether they
are Customer 100, 101, 102, etc., I could get their number and use this as
the ID into my own tables when I need to query for their data.

Does this make sense???

I know this may not be how Membership provider is typically used -- since I
don'e have clearly defined roles for one person like Admin, Developer, User,
Publisher, etc., and I'm not trying to restrict specific web pages from
displaying... I'm mainly trying to determine what Customer # they are so I
can display a gridview with only their data.

 

[clintonG]

Membership will generate and assign a GUID for each user. You are advised to
use that GUID as the classes and methods are there for us to apply to such
tasks you are discussing for identifying and controlling access and
authentication.

Finally, you still missed the point I tried to convey. Membership and Roles
can be used to determine what can and what cannot be seen on a page right
down to the paragraph and the sentence if wanted using templates as the
snippet example below shows. The use of templates is granular and gives us a
lot of control.

You have to do the work to learn 2.0 templating as ASP.NET templates have
become the way most of the classes get things done.

// Learn the LoginView Class
<RoleGroups>
<asp:RoleGroup Roles="Guests">
<ContentTemplate>
will only display content in this section of the
page for users logged in who have been assigned
to the Guests role.
</ContentTemplate>
</asp:RoleGroup>

I respect Cowboy's skills and experience but for some reason his advice to
you was misleading and your ideas? Well, he has suggested I should lighten
up on people with crazy ideas ;-)

So in summary, use the GUID to identify the logged in user and use the
LoginView class to determine what can and cannot be accessed on the page.

Finally, use this [1] as it beats the hell out of the lame and buggy shit
Microsoft put in the "box" and has to my knowledge left FUBAR for developers
to work-around the bugs and cope with incompleteness on their own.

<%= Clinton

[1] http://www.qualitydata.com/products/aspnet-membership/default.aspx