Following up on my implementation of the 'samesite' cookie attribute in sessions, I've been using 'pyramid_redis_sessions' in most applications, but one uses 'pyramid_beaker' with Redis because it also needs to support file-based sessions.
I thought 'pyramid_beaker had ended development with Pylons, but I was surprised to see it has had several new commits over the past year and has both 'samesite', 'secure', 'httponly, and a Redis backend, all things I've needed. 'pyramid_redis_sessions' seems to be unmaintained, and a 'pyramid_session_redis' has appeared to supersede it. It also has a bunch of features for high-volume usage that I don't understand. That made me start thinking about switching from 'pyramid_redis_sessions' to one of the other two. But I find that different applications have different needs and may need different session libraries. 1) Restricted site with logins. This one changes the session timeout dynamically. The default timeout is 1 minute for bots. The unauthenticated timeout is 20 minutes for the user to complete the single-sign in procedure on the authentication server. The authenticated timeout is 2 hours after a successful login. I use a 'pyramid_redis_sessions; method to change the timeout. 'pyramid_beaker' odesn't seem to have this, and I haven't checked 'pyramid_session_redis' yet. But 'pyramid_redis_sessions' doesn't have 'samesite', which the other two do, and my IT department may insist on it at some point. 2) A public site flexible for Redis sessions or file-based sessions, with non-JSONable data in the session(i.e., it requires Pickle serialization). It's currently using 'pyramid_beaker'. I asked earlier on this list whether my Pickle-based sessions would still work under Pyramid 2, and was told that JSON is just the new default, not a requirement, so I could confinue using an a existing session library that supports pickling. 'pyramid_session_redis' has a statement in its documentation saying it's moving to JSO(N, and it's unclear to me whether it would still sopport Pickle in some configuration, or if I'd have to write my own plugin. Making the session data JSON-safe would require rewriting significant parts of the application because it uses nested objects. 3) A public site that just needs basic session support, and is currently using 'pyramid_redis_sessions'. that doesn't support 'samesite', which I may need someday. Do you have any advice on these tradeoffs? -- Mike Orr <sluggos...@gmail.com> -- 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 pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DuoGDyYROsP3X9dQjj7-CuE03Qz7yxLkNCueSipOD0TbjA%40mail.gmail.com.
