views:

390

answers:

8

Hi,

I am making a website in ASP.NET and want to be able to have a user profile which can be accessed via a URL with the users id at the end. Unique identifier is obviously a bad choice as it is long and (correct me if i am wrong) not really URL friendly.

I was wondering if i produced a unique idnetifier on the ASP page then hashed it using CRC (or something similar) if it would still be as unique (or even unique at all) as just a GUID.

For example:

The GUID 6f1a7841-190b-4c7a-9f23-98709b6f8848 equals CRC E6DC2D44.

Thanks

+2  A: 

Any calculated hash contains less information (bits) than the original data and can never be as unique. There are always collisions.

Tommy Carlier
A: 

If you use a CRC of a UUID/GUID as ID you could also use a shorter ID in the first place.

The idea of an UUID/GUID as ID is IMO that you can create IDs on disconnected systems and should have no problem with duplicate IDs.

Anyway who is going to enter the URL for the profile page by hand anyway?

Also I see no problems with URL friendliness of an UUID/GUID - there are no chars which are not allowed by http.

Fionn
+8  A: 

A CRC of a GUID would not be unique, no. That would be some awesome compression algorithm otherwise, to be able to put everything into just 4 bytes.

Also, if your users are stored in the database with a GUID key, you'd have trouble finding the user that matches up to this particular CRC.

You'd be better off using a plain old integer to uniquely identify a user. If you want to have the URL unguessable, you can combine it with a second ticket (or token) parameter that's randomly generated. It doesn't have to be unique, because you use the integer ID for identifying the user. You can think of it more or less as a password.

Thorarin
This looks like the best solution. Thanks.
A: 

No, it won't be as unique, because you're losing information from it. If you take a 32 character hex string and convert it to an 8 character hex string then, by definition, you're losing 75% of the data.

What you can do is use more characters to represent the data. A guid uses ony 16 characters (base 16) so you could use a higher base (e.g. base 64) which lets you encode the same amount of information in fewer characters.

Greg Beech
A: 

I don't see any problem with the normal GUID in HTTP URL. If you want the shorted form of Guid use the below.

var gid = Guid.NewGuid().ToString("N");

This will give a GUID without any hyphen or special characters.

Ramesh
A: 

How are users identified in the database (or any other place you use to store your data)?

If they are identified using this GUID I'd say, you have a really good reason for this, because this makes searching for a special ID really complicated (even when using a binary tree); there is also more space needed to store these values.

If they are identified by an unique integer value, why not using this to call the user profile?

Manuel Faux
A: 

A GUID is globally unique, meaning that you won't run into clashes, hopefully ever. These are usually based on some sort of time based calculation with randomness interjected. If you want to shorten something using a hash, such as CRC, then then uniqueness it not automatic, but as long as you manage your uniqueness yourself (checking to see if the hash is not currently assigned to another user and if so, regenerating until you get a unique one) then you could use almost anything.

This is the way a lot of url-shorteners work.

Kitson
+1  A: 

If the users have a username then why not use that? It should be unique (I would hope!) and would probably be short and URL friendly. It would also be easy for users to remember, too, and fits in the with the ASP.NET membership scheme (since usernames are the "primary key" in membership providers). I don't see any security issue as (presumably) only authenticated users would be able to access it, anyway?

Dan Diplo
Username is elegant, but you're out of luck if you want to produce a permanent link and still support changing usernames. Small design consideration.
Thorarin