As far as I undersand, API KEY is not something like ID, it's more like a password for user's website URL, so it does not necessary have to be unique.
For example, when you register an account for GMaps, you get an API KEY for a specific URI. Aidas Bendoraitis [aka Archatas] On 8/11/06, Felix Ingram <[EMAIL PROTECTED]> wrote: > > On 8/11/06, Jay Klehr <[EMAIL PROTECTED]> wrote: > > Felix Ingram wrote: > > > On 8/10/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > >> Just username+randomstring is good. > > >> SHA better than md5. > > >> > > > Choice of hashing algorithm means nothing here. The only thing about > > > SHA is that you'll get a longer string (160 bit rather than 128). > > > > > > If all you want is a random string then just use a random string. > > > > > However, a longer string gives you more unique combinations before you > > have a collision. > > Well that's true but 128 bits still gives you 3 x 10^38 possible > strings, so you could probably give everyone on the planet a key an > still not have a collision. > > > I do agree that one small piece of non-random information will protect > > you more against duplicates though. That way, if the same random number > > is generated for two different users, they wouldn't turn out to be the > > same hash (using either MD5 or SHA). > > > > Say we have firstnames and two users get the same random bit added to > > the firstname when generating their key: > > > > paul + 78uyy5jji = ADB01D7112EC1296DB1DFA87E37036B1 (md5) > > julie + 78uyy5jji = A6EC2D3C8E0C831012F05E7A1EB4E080 > > > > Obviously if you only used the random bit, a duplicate key would be > > created here, both users would end up with the same key: > > > > 78uyy5jji = C5E9348386E8DECF6DDC879E7E914B92 > > > > Of course, you should use a longer random string than my example here, > > which would reduce the chances of getting a duplicate, but I still > > recommend using some part of the user's profile (or even a timestamp) if > > you're going to use MD5 or SHA. > > I do not think that recommendation makes much sense. In your example > which is more likely: two random strings of length 4 being the same or > two users being called 'paul'? Timestamps are better but what does > this add? As soon as one uses a random string then the resulting api > key, no matter what you add or what algorithm you pass it through, > will still only be as random as the string itself. If you are worried > about collisions then generate a longer random string. > > > Really, using a 128 bit or 160 bit (recommended) random string is all > > you need to do, but MD5 and SHA make that step easier. > > . > > They don't though do they? If you're generating a random string then > it's as easy to generate one of a particular length that one of > another. Adding timestamps or user details is going to cost you > performance and space. Are you going to store the timestamp used? If > so then why? > > Which of the code examples below is more random/more secure and why? > > =========== > from random import choice > > characterSet = '[EMAIL PROTECTED]&*(-_=+)' > api_key = ''.join([choice(characterSet) for i in range(50)]) > =========== > > import sha, random > > username = request.user.username > api_key = sha.new(username + str(random.random())).hexdigest() > > =========== > > No matter what you do there is always a chance for a duplicate key to > > come up (something you should check in your system before assigning), > > but the longer the key, the less likely that will happen. But too long > > and your users will hate you. ;) > > There are two things you can decide to do. Decide that you trust your > random key generator and that the probability of a collision is > sufficiently low for you to just hand out keys, or decide to implement > a check and take the performance hit (which should be minimal in the > grand scheme of things). > > Felix > > > > > Jay > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
