asp.net mvc - membership provider

Question

For my ASP.NET MVC app, I just find dealing with unique-identifiers harder, so I have added my own field to ASPNET_USERS table - UserIdInt (which is actually a bigint!) So most of user operations use userIdInt as reference.

Anyway, I am debating between two approaches:

1)When a user logs in, look up from the database and store the userIdInt in a session variable and any-time session variable slips away, re-look it up and put it back in session variable. (It's okay to use sessions in MVC app, right?)

2)Any time an operation needs to be performed, simply pass userName to database and take care of UserIdInt at database side by doing joins and such on ASPNET_Users table any time an operation from user needs to be performed.

I am heavily leaning towards 1)... but I want to make sure I am on right track.

I asked this question on Serverfault first, but I was told to ask this question here.

Answer 1

An alternative approach is to alter the forms authentication ticket to add your unique id to the data stored in the cookie. Then, by implementing a custom IPrincipal you can have your unique id available anywhere that the User object is available.

Answer 2

progtick,

you may be far better looking into the use of custom profile providers as this would allow you to leave the aspnet_* tables as is (which is a good idea in case a later version of sqlserver changes how they operate) plus offer the additional bebnefit of having a multitude of additonal profile related properties availabale to your application. i can't overstate enough the benefits in going down this track as i've found it very useful to have such an approach in both my standard asp.net apps as well as my mvc ones.

you can get a feel for what's involved in this by looking thro a couple of these links: here's one on SO for starters:

Implementing Profile Provider in ASP.NET MVC

and one from my old mate, lee dumond:

http://leedumond.com/blog/asp-net-profiles-in-web-application-projects/

hope this helps