views:

326

answers:

1

I'm swimming in the relationships and hierarchies of a web application that I'm trying to secure with custom sql membership and role providers. I'm a little fuzzy on forms authentication, principals, and the like. So --

The web.config is set up for forms authentication with a custom membership provider and custom roles provider.

When my fictional web app starts, it validates user logins from the database using methods from my custom membership provider.

At this point, I assume that it sticks the providerUserKey into a principal object that is stored, encrypted, in a cookie?

If I want to include other information in each page about a user, such as a foreign key (ID) to another table in my existing system, what's the best way to persist it to avoid round-tripping to the database?

Do I extend the principal to include this extra field? Do I extend the membership object to include this extra field? Do I create a custom profile provider and use that to store the extra field?

Where are all of these identifiable pieces of information stored? I had assumed that a custom profile provider would be accessible without a database round trip once the user had logged in.

A: 

I would use a custom Profile provider and cache (in session) the user's profile in order to eliminate unnecessary round-trips to the database.

Jimmie R. Houts