Why is the asp.net user ID not stored on the ticket ID?

Question

I looked at binding my own user table to an asp.net membership, storing my userid (int) in the UserData area of ​​the authentication cookie ( Storing and accessing an outdated UserID in the asp.net membership ).

As my application for my own use, and also to help me learn asp / C #, I thought it would be nice to compare the efforts to set up the membership so that it matches my database with the opposite (i.e. use membership from and edit my database accordingly).

If I convert my database to use UserAs guid (uniqueidentifier) ​​identifiers as foreign keys in all tables associated with my users, then I still need a way to make UserID easily accessible for my application. The approved way to get the UserID looks like this:

Guid userID = (Guid)Membership.GetUser().ProviderUserKey; 

Now, if I understand correctly, this is related to reading the database. I may be picky, but apparently this is a little superfluous for every request. I would be inclined to put it on the ticket. I see no problem putting the PK value on the ticket (guid or int). Is there a security risk? Membership seems happily using UserName as a key, not a surrogate. What begs the question - why didn't they put the UserID on the ticket?

Answer 1

Cookies and URLs have a practical maximum length - FormsAuthenticationTicket.UserData documentation says:

"You must limit the amount of data stored in the UserData property. You must ensure that the size of the UserData property does not result in an invalid cookie or an excessively long URL."

ASP.NET can be configured to use cookie validation , which stores the authentication ticket in the URL. In this case, the ASP.NET ISAPI filter also needs to do a bit of extra work to remove the ticket information and then rewrite the URL.

Thus, part of the reason can probably be related to a compromise on keeping the minimum length of cookies / URLs by default - storing an encrypted serialized Guid in a ticket would increase the length of the cookie / URL, as well as an additional limit (not provided in to a large extent) the amount of data that you can save in UserData .

Answer 2

You can always write your own UserPrinciple that implements IPrinciple, which can give you the user ID once, and this can be called anywhere in the application without actually getting into the database. Then you can use userId in the cookie if you want.