4

I was looking at linking my own User table to the asp.net membership by storing my userid (int) in the UserData area of the authentication cookie (Storing and accessing a legacy UserID in asp.net membership).

As my application is for my own use and also to help me learn asp/c#, I thought it might be a good idea to compare the effort of tweaking membership to fit my database with the reverse (i.e. use membership out of the box and adjust my database accordingly).

If I convert my database to use guid (uniqueidentifier) UserIDs as foreign keys in all my user related tables, then I still need a way to make the UserID easily accessible to my application. The accepted way to get the UserID seems to be like so:

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

Now, if I understand correctly, this involves a read of the database. Perhaps I'm being picky, but it seems a bit unnecessary on every request. I would be inclined to put it in the ticket. I can't see any problem with putting a PK value in the ticket (guid or int). Is there a security risk? Membership seems to be happy using the UserName as a key rather than the surrogate. Which begs the question - why didn't they put UserID in the ticket?

Community
  • 1
  • 1
Fruitbat
  • 764
  • 2
  • 5
  • 19
  • You could use a custom membership provider that links your int-IDs with the GUID's, for example: http://stackoverflow.com/questions/6532418/how-to-combine-using-membership-api-with-own-application-related-data/6532611#6532611 – Tim Schmelter Feb 15 '12 at 15:41
  • @TimSchmelter - This is, essentially, what I am doing. I'm just wondering why the userid with the out-of-the-box membership is not stored in the authentication ticket. Did they forget or is there a good reason not to put it there. – Fruitbat Feb 15 '12 at 15:55

2 Answers2

1

Cookies and URLs have practical maximum lengths - the FormsAuthenticationTicket.UserData documentation states:

"You should 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 cookieless forms authentication, which stores the authentication ticket in the URL. In this case the ASP.NET ISAPI filter also has to do a bit of extra work to strip the ticket information then rewrite the URL.

So part of the reason can probably be attributed to a trade-off of keeping the default cookie/URL lengths to a minimum - storing an encrypted, serialized Guid in the ticket would increase the length of the cookie/URL, and also further limit (granted not by much) the amount of data you can store in UserData.

kuujinbo
  • 9,272
  • 3
  • 44
  • 57
  • This seems to be plausible at the very least. Certainly, if username is unique, it covers both functions of display name and database key. Although as far as I can see, uniqueness of username is not a database constraint, but a check in the CreateUser stored procedure. – Fruitbat Feb 20 '12 at 07:56
  • 1
    Yes, puzzling why username is not a *table* constraint. I think the Membership providers were intentionally written to balance scalability and flexibility. Features were probably left out of the API because Microsoft expected developers to roll their own provider(s) if needed. Not one to throw around praise to MS ;-), but IMHO they did a pretty damn good job. At my previous job I did *real* development work, and heavily used the `UserId` (as you intend?). Instead of writing a provider, created a static helper class with a bunch of methods that among other things, cached `UserId`. – kuujinbo Feb 21 '12 at 09:02
0

You can always write your own UserPrinciple implementing IPrinciple which can give you the userID once and this can be called anywhere in the application without actually hitting the database. Then you can use the userId in cookie if you still want to.

Bilal
  • 182
  • 13