Michael, Ben, Thank you very much for your responses and suggestions!
I wasn't convinced that the cache would be a good way of doing what I wanted to do - and indeed, it really sounds like a bad idea now that I have a better understanding of how this works. This is plenty of ammo for me to continue developing. To answer your question Michael, I wanted something to store data that would not get sent back to the user (and hence could not be tampered with), but still be associated with their session, and that would expire automatically after some time. Thank again! Damian On Dec 2, 5:52 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Dec 2, 10:10 am, Damian <[EMAIL PROTECTED]> wrote: > > > 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 not understanding why the cache should be involved at all here. > If you are storing persistent (meaning, can't randomly disappear), per- > user data, that's what the HTTP session is used for. In beaker, the > session uses the same backends as the cache system, except its stored > in a way that is appropriate for individual user data. the cache > system is specifically for website content that isn't keyed to > specific identities. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
