views:

1472

answers:

4

How do I generate a unique sission id in Python?

+12  A: 

You can use the uuid library like so:

import uuid
my_id = uuid.uuid1() # or uuid.uuid4()
Sverre Rabbelier
That's what I was looking for!
Alex
But that’s not very random.
Gumbo
@Gumbo: please elaborate?
saffsd
@Gumbo: uuid will use the things like the mac address and uptime of your computer to come up with a random uuid, why is that not random?
Sverre Rabbelier
+1  A: 

It can be as simple as creating a random number. Of course, you'd have to store your session IDs in a database or something and check each one you generate to make sure it's not a duplicate, but odds are it never will be if the numbers are large enough.

David Zaslavsky
Exactly, Hence my solution: http://stackoverflow.com/questions/817882/unique-session-id-in-python/818040#818040
Seun Osewa
+1  A: 
import os, base64
def generate_session():
    return base64.b64encode(os.urandom(16))
Seun Osewa
why the downmod?
Seun Osewa
I duno, but this appears to be a valid solution. However, I'd advise you to strip the trailing "==" and also include a time stamp for less chance of a collision.
Unknown
The chance of a collision after 4 billion iterations is 1 in 8 billion. If I want to reduce the chance of a collision further I can just increase the number of bits i.e. os.urandom(32). And I don't understand what stripping the trailing "==" is supposed to achieve.
Seun Osewa
The trailing == can be removed to save space. All you have to do to decode it is to pad it back to the highest multiple of 4. Using urandom, it is possible to get very low entropy and end up with a duplicate. Using a timestamp is better.
Unknown
Really? (I don't see how a 4-byte timestamp is better than an additional 4 bytes of randomness, but) if what you say about low entropy is true, then I would go for an auto-incrementing session_id since it's possible for many session requests to be issued roughly at the same time. Even in a low entropy situation, I don't except urandom to ever return a duplicate 32-byte string. Pseudorandom algorithms may be attackable, but they don't return duplicate 32-byte sequences.
Seun Osewa
In a totally random system it is possible to return even a duplicate 32 byte string. In a low entropy system, this is even more likely. If you know that your computer can only spit out a session only so fast (ex. every 5 milliseconds) the minimum time it takes to execute that command, then this becomes a strict guarantee that you will never get a collision which is better than random.
Unknown
I think it's ridiculous to complicate your session generator because of something that's "possible" but probably hasn't EVER happened before. Like, say, our planet suddenly exploding.Yes, it would be "safer" to never leave your house without a mobile lightning rod because it's "possible" that you'll be struck by lightning, but it's also very ridiculous.Even if your computer can only spit out a session every 5ms, it's "possible" that two attempts to generate a session will be initiated concurrently on different processors in a multicore system. Do we need a processor id too?
Seun Osewa
A: 

what's the session for? a web app? you might look at the


beaker

module. this is the default module for handling sessions in pylons.

http://beaker.groovie.org/

blackkettle