Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've come across this is in a couple of different applications that I've worked on. They all used the ASP.NET Membership Provider for user accounts and controlling access to certain areas, but when we've gotten down into the code I've noticed that in one we're passing around the string based username, like "Ralph Waters", or we're passing around the Guid based user ID from the membership table.

Now both seem to work. You can make methods which get by username, or get by user ID, but both have felt somewhat "funny". When you pass a string like "Ralph Waters" you're passing essentially two separate words that make up a unique identifier. And with a Guid, you're passing around a string/number combination which can be cast and made unique.

So my question is this; when using Membership Provider, which do you use, the username or the user ID to get back to the user?

Thanks all!

share|improve this question
up vote 3 down vote accepted

I use the GUID since it is guaranteed to be unique.

share|improve this answer
While it's not as friendly to say as an integer ID, I have to admit that the Guid is probably the best choice between the username and the userid that Membership Provider gives us. – Chris Feb 23 '11 at 16:31

I almost always write a custom membership provider. It's not that hard and you can use whatever you want.

share|improve this answer
Agreed, but IIdentity still only offers one "Name" property. So the question could morph into when using IIdentity, which do you store in the Name property, ID or username? – Portman Feb 23 '11 at 3:32
@Portman You can store other properties in custom IPrincipal/IIdentity implementation – LukeP May 10 '12 at 9:37

A name can never be unique. The only (?) way to make it unique is to append a unique identifier to it. At that point, you've just added a lot of complex string handling for no significant return. You're better off creating or using a unique identifier and getting the name for display only.

share|improve this answer
"Username" is typically, if not always unique. Note that "username" is very different from "user's name". – Portman Feb 23 '11 at 3:33
The OP gives the example of 'Ralph Waters', which is a "user's name". – Michael K Feb 23 '11 at 13:40
@Chris: If that name is guaranteed to be unique, than it would be ok, and as OP said, would work. The problem then devolves to a preference of which ID to use. Personally I think I'd use the GUID, but that's me. – Michael K Feb 23 '11 at 14:23
Actually when you create an account with Membership Provider you can have a username with "Ralph Waters". The entire string, both words and the space are considered the username and are needed for logging in. Hence my questioning if using the username is a good thing to do when needing to reference a member from the aspnet_users table. – Chris Feb 23 '11 at 14:25
I agree, using the unique ID would be a much better choice in the long term. When I've used both methods, I felt that passing around a name was just 'wrong'. The only issue I have with a Guid is that it's just not friendly like an integer would be. – Chris Feb 23 '11 at 14:27

It depends on the membership provider you are using. Hopefully you are not using the default SQL one on anything important too complicated.

share|improve this answer
Can you go into more detail about this statement: "not using the default SQL one on anything important."? – Chris Feb 22 '11 at 21:27
The default sqlmembership provider is a thin in places. It does not give you much flexibility w/ user attributes and it has little redundancy in it's security mechanisms, although to be fair much of that weakness is when combined with the default controls. For example, the "role" section of that provider is often stored in an encrypted cookie. Most of the time that is fine, but if you have a large number of roles it pukes when the collection gets too big and some of the default tools do not work without the cookie. It also does not have a very good way of storing a complex attribute. – Bill Feb 22 '11 at 22:47
That's interesting in that I have never experienced those issues before. Thanks for the information. – Chris Feb 23 '11 at 2:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.