The focus of this discussion shouldn't be the merits, drawbacks, or implementation details of server-side sessions vs client-side sessions -- which everyone is quick to chime in on. We can talk about that all day. We have, many times..
My concern isn't that there is a session_id variable in every session or the uniqueness of said id. My concern is that there should be standard way in which Pyramid plugins use and expose the raw session_id of server side sessions. Because ISession doesn't have a session_id , everyone has implemented this differently. Without some sort of official stance, everyone in the future will implement this differently. A consensus on this would allow for server-side session libraries to be swappable -- switching from Redis to Memcached; or "pyramid_redis_a" to "pyramd_redis_b". I understand that "client side sessions" are "basic enough". However, server-side sessions all rely on a raw cookie value as their session id. It's a technological given. My concern isn't on the merits of whether or not that ID should be trusted, if it is valuable, or what it should be used for. My concern is the lack of a standard in the pyramid ecosystem for dealing with this common situation. Instead of having a familiar api when dealing with sessions or writing new packages, and more interoperability / swap-ability of plugins... the project is opting for a "no rules" approach on this matter, stating that the client side sessions are basic enough. That doesn't sound like a compelling argument to me. And instead of addressing the fact that server-side plugins are left to approach this differently -- and have been doing just that -- the utility and motives of the data are being questioned. Even if the underlying session_id were 100% worthless, there would still be tangible benefits if every session library in the pyramid ecosystem tracked that variable in an unified way ( readability, familiarity, maintenance and collaboration between projects ). Unlike many other Python frameworks which left the entirety of sessions to third parties, or left their sessions entirely undocumented and largely unreliable, Pyramid crafted a richly documented sessioning system with an official interface/api for implementation and an expectation for libraries to be built upon it. The interface is exacting on how to deliver on virtually every core sessinoning feature. The sole omission -- how to provide for the session_id in server-side sessions. That being said, if you want to talk about the utility of a session_id variable: We actually prefer user and "logged-in-event" logging , and do that with our own Business Intelligence systems. The latter is essentially what Bert described ( though we use a serial instead of a uuid ). The desired "session_id" logging gives parity from our Python logs to our webserver logging -- which can only access raw header/cookie values. Third party analytics systems, driven by PHP's popularity, expect to see this and will segment on the logged session-id. Some of the proposed solutions wouldn't solve our needs, because they stash a unique ID within the session. That solves a completely different problem. Placing a UID/UUID within the session data works perfectly for accessing and utilizing a UUID for a session within python. But one must use a specific session library to load and extract that identifier from the session payload. That's not what I'm interested in. This internal UID is not available on the proxy/gateway server nor is it available on nginx/apache, mod_security, other server plugins or various other server systems that touch our http traffic. Those can only access the raw plaintext cookie value. The internal uuid is not necessarily available to python outside of Pyramid either, unless one goes so far as to create a middleware package to offer it onto other sections of the WSGI stack. I am interested in the raw cookie value, which appears across all the various systems in our technology stack and is used as the key in the datastore ( or can be computed to derive that key ). Also in the "utility" column -- when dealing with "realtime" performance logging systems like Cube / StatsD, we use the SessionID to give us transparency across every element in our stack. Everything can access it, so everything can log based on it. We also insert a uuid into the header on the gateway to serve as a "request_id". session data is often more useful than request data though. Usually you don't want to use "highly unique" values for StatsD, but we discovered a handful of use-cases for using the SessionID to identify bad behavior, or track session activity within a subset of URL paths. To close out a few sidenotes: - I thought i was clear that I was talking specifically about Server Side sessions, not client side ones. - I am fully aware that Client Side sessions do not have a ID. I'm not advocating that they offer an id or should offer an id. I am advocating for a unified session_id interface for server side sessions. - When it comes to server side sessions, virtually every framework has a documented "session_id" variable OR a general consensus on what to use when developing Plugins. - Flasl does use signed cookies by default. BUT there is an extensive section on the docs for Server Side Session support. All the server side sessions examples in the Flask documentation use .sid ( http://flask.pocoo.org/snippets/category/sessions/ ) - I based my tornado comment by going through the sourcecode of multiple session libraries from the Tornado wiki. - Bert's session package is great, but also illustrates this issue. He made an arbitrary decision to use `_session_id`. Packages released under his system would be largely compatibile with one another; but since there is no official implementation from pyramid, the session_id should be expected to NOT be compatible with other pyramid session packages. -- 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/d/optout.
