On Dec 2, 2008, at 7:10 AM, Damian wrote:
""" Creates the random cache """ import random rand = str(random.randomint()) while check_key_in_cache(rand): rand = random.randomint() registrationcache = cache.get_cache(rand, type='memory', expiretime=6000) session['mycachekey'] = rand session.save()The user does not have a login or unique id that I could use otherwise at this stage. Essentially, I want to avoid having to create entries in a database for this, and then having a cronjob clean out old data.
If you're using Beaker for sessions, you do have a random key, the session id. It's just session.id, and will give you a specific value for the user thats unique.
I want the cache to 'clean itself' after some time, while maintaining unique caches for each user for some amount of time. Is this a reasonable approach? Is there a way to delete a cache (not just clear it)?
Sure, it depends on what backend you're using. If you use memcached you never have to clear it, as memcached will clear it after its not been accessed for awhile. While with the file-based, you can go through the files clearing ones that hit a certain age with no modification.
How does the expiretime work?
The expiretime is used to determine if the cache needs to be created again. Consider this:
def make_value():
# do something here that results in the value to cache
registrationcache = cache.get_cache(rand, expiretime=6000,
createfunc=make_value)
So when Beaker checks the cache, and sees the current time vs the expire time, if its expired, it runs the function to make the value again, and stores it. That's all the expiretime is used for by Beaker itself, to determine upon cache access, if its still valid or should be regenerated.
The above may be used in a multi-page registration where I do not want users being able to tamper with things in the session. I'm guessing another option woud be to encrypt the bits of the session I don't want the user messing with, and achieve a similar result.
I'm a big fan of never holding onto this state on the server. In the past, I usually either store it in the users session (though that gets rather big), or I keep the values along inside the form itself (and later pages of the form inherit their validation schema from the prior pages, so everything is checked before the final page). If you're doing things and having other state that needs to be retained between pages, I've gone the route of pickling the data for the multi-page signup, and putting that in as a hidden input field with a hidden HMAC signature (like how session integrity is kept).
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
