On Dec 12, 2013, at 20:53 , Mike Orr <[email protected]> wrote: > On Thu, Dec 12, 2013 at 10:12 AM, Bert JW Regeer <[email protected]> wrote: >> If you need server side sessions (and I would take some time figuring out >> why you need them) take a look at pyramid_redis_sessions for example. > > How can you store search state or the logged-in user without sessions?
Server side sessions (where the session is stored server side) doesn’t require this, you can store the information in a cookie without issues. > Sometimes you can replace sessions with cookies, but cookies have a > size limit, can be arbitrarily modified behind your back (meaning > you'd have to revalidate the data on every request) This is why you sign the data you send in a cookie. Yes they have a size limit, of 2093 bytes. If you are storing information longer than that, then yes you may require server side storage of some sort, but you may also want to consider refactoring code or figuring out why so much data is being stored in the session. > , and you may have > internal data you don't want to reveal directly to the client. Feel free to encrypt it, there is no requirement that cookies are sent in the clear. The default implementation currently signs and base64’s the data to be cookie safe. > The > REST people always said sessions are bad but they never addressed an > adequate alternative. You can store "session" data in database tables > keyed by session ID, but session data is often more hierarchical than > your regular database objects, so you'd end up either creating as many > related tables as the rest of oyur application has or pickling it... > and if you pickle it then that's essentially the same thing as a > session except you have to write the code to fetch and save it > yourself rather than having the session infrastrucure do it for you. There is no reason why you can’t use the session stuff to pickle/depickle all you want and store the key in a cookie. The two are not mutually exclusive. For example, at the moment you could take SignedCookieSessionFactory in Pyramid 1.5a3 for example, add a custom serializer that stores the information about the session into the database, and sends a unique ID to the client. With datastores like PostgreSQL being able to store stuff in json or blobs you can accomplish this. Using sqlalchemy you can then add caching using dogpile.cache simply. The current SignedCookieSessionFactory for example pickles the information to be stored, signs it, then base64 encodes it and sends it to the client in a cookie. Upon the client requesting a new page the content is base64 decoded, the datas signature is verified so it can’t have been tampered with, and then the data is unpickled. This solves the problem of having to store the session server side, instead you let the client keep the information. > >> >> >> It has been mentioned that using dogpile.cache for sessions doesn’t make >> much sense, see this comment by zzzeek: >> http://techspot.zzzeek.org/2012/04/19/using-beaker-for-caching-why-you-ll-want-to-switch-to-dogpile.cache/#comment-532502543 > > In that case zzzeek gave an incorrect impression of what Dogpile would > be. He said it would be a replacement for Beaker. The vast majority of > Beaker users are using it for sessions, and only a few for caching. > There are replacements for beakers session implementation... That being said, Beaker too contains a cookie only session implementation that signs the data and stores it in a cookie, it is called beaker.session.CookieSession. It does the exact same thing as the SignedCookieSessionFactory that is included with Pyramid. > >> Use a signed/encrypted cookie to have the session store off-loaded to the >> client, or store the data into a database and use it WITH dogpile.cache to >> provide caching as appropriate (sqlalchemy with dogpile.cache for example), >> and return a cookie that contains a unique ID that associates it with the >> database data. >> > > Since a session is essentially a cache, I think a pyramid_dogpile > would just be a matter of a Pyramid.ISession front end to > dogpile.cache. Yes, indeed it would be. It’s not that difficult to implement. See the CookieSession implementation here: https://github.com/Pylons/pyramid/blob/master/pyramid/session.py#L222. Just make sure to figure out all of the edge cases with using a caching library for getting/setting data that is not really a cache but a mutable object. Why not just use redis or memcache directly at that point? > I haven't looked at it closely but I think Pyramid has > at least some of the support for the cookie part. I don't understand > what the "lot of other work" zzzeek is referring to is. I assume that zzzeek is referring to the mismatch that is using dogpile.cache for something that it wasn’t meant to do. > > If we're going to transition people away from sessions, it should be > done in a deliberate way with documentation and tutorials, not just > letting the session infrastructure stagnate until it dies away, > without even telling people it's going. Especially when Pyramid and > Pylons have been recommending sessions for so many years. The sessions infrastructure isn’t disappearing. Not in the slightest. pyramid_beaker is simply ONE implementation of sessions. pyramid_redis_sessions is another, SignedCookieSessionFactory is one that is included by default. There is simply no reason to call out pyramid_beaker when a perfectly good session implementation is included with Pyramid. Not only that but both pyramid_beaker and Beaker are in maintenance mode, they are not getting new fixes or code and even the authors themselves have suggested finding alternatives. There is no transitioning away from sessions, sessions are here to stay. The question is how to implement said session infrastructure in the best possible manner with the least amount of effort. I personally highly recommend looking at storing session data in a signed cookie. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out.
