On Tue, Apr 22, 2014 at 1:16 PM, Anders Wegge <awe...@gmail.com> wrote: > As I read the documentation for SignedCookieSessionFactory, the data stored > in the session is not encrypted. So storing a CSRF token in the session > Cookie is not a good option. Pyramid_beaker seem to have been deprecated > with release 1.5, so which options are the best for a site with very few > actions requiring CSRF and other session data.
I've used Beaker with Pylons for several years and pyramid_beaker for several months without any problems. When I heard about the deprecation I was unhappy, but later decided to try pyramid_redis_sessions anyway to evaluate Redis for more widespread use (caching, usage stats, all data). So I compiled Redis and set up pyramid_redis_sessions, and it's working flawlessly. The 'pyramid_[session]' packages are all pretty small; most of the code is in the backend packages. The reason Beaker's creator stopped supporting it is it's old, messy, hard-to-maintain code. It was originally ported from Perl::Mason via Myghty circa 2005. Since then we've learned a lot more about the virtues of modularity and what contemporary web applications need. Dogpile is a "clean" renovation of Beaker's storage system. It's really only one of Beaker's backends, so it's not a complete replacement of Beaker. There are now three fundamental questions for session-adapter developers. Do we want to replicate Beaker with a full variety of backends, including Dogpile and database and others? Or do the 'pyramid_[session]' packages sufficiently replace the Beaker frontend, and we just need to make 'pyramid_[session]' packages for the full variety of backends? Or move away from sessions? In Beaker's time, everybody used sessions if they had inter-request temporary data. Now some people prefer to store it all in client-side storage (cookies, Javascript variables, HTML 5 storage) to avoid the scaling issues of server-side sessions. Others maintain a session ID but store all the data in ordinary database tables. (That gets complex if you need 1:many tables.) Others do other things I don't understand. I use server-side sessions because (1) I have large pieces of data like all the result IDs from a search, and (2) sometimes i don't want the client to see the data directly. The main usability difference between Beaker and the 'pyramid_[session]' packages is that Beaker has a unified configuration API for its backends. To switch backends you just change one INI setting. But with the 'pyramid_[session]' packages you have to change your includes and dependencies, and each one has different settings variables. I had to switch from one requirements file to several, to allow people to use various session packages without installing all of them. So that would be the advantage of a unified Beaker replacement: a unified configuration. But it's not an overwhelming advantage, because the 'pyramid_[sessions]' packages also work pretty well, and have the advantage of being independent. So ultimately we need either a Beaker replacement or packages for file sessions and SQL-database sessions. I guess Memchached is obsolete now that Redis can do the same? I'm also exploring some alternatives for Redis, such as putting the session in a Redis hash rather than a Redis string, with the values as either pickle or JSON. That would make it easier to manage sessions in the Redis CLI rather than just having opaque Python-specific pickles. I tried a bit to make a 'pyramid_dogpile', and to store data in database tables, and to modify Michael's module to keep the same session ID, and other things, but they're all so complicated. Pyramid 1.5 makes it a little bit easier because it includes some signing stuff that previously each package had to maintain. 'pyramid_redis_sessions' hasn't yet caught up to that code yet. (Although it's really the same code, just in a different place.) I also wish Pyramid had the foundations for generating session IDs and saving them in cookies and keeping the same ID, because those are the hardest parts of writing a backend. Again, Beaker has it all, but it's hard to extract code from Beaker because it's so messy. I also ran into an issue the Beaker puts the session ID in the session as an attribute (session.id) but pyramid_redis_sessions doesn't. That caused me problems because I was keeping the session IDs in my access log to count the number of sessions per month, their lengths, and entry and exit pages. I couldn't figure out how to do that with pyramid_redis_sessions. Finally somebody suggested putting a different random ID in the session, independent of the session ID, and that worked. -- 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 post to this group, send email to pylons-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
