Ignoring everything else for the moment, you've already made yet another assumption that you're not going to be happy about. The raw cookie value is in no way a session identifier. For example in pyramid_redis_sessions the session identifier is cryptographically signed to prevent clients from even attempting to guess other session identifiers, and arguably it should always be signed. And pyramid_redis_sessions also pickles the contents so its unusable outside of Python by default (while providing hooks to change that if you need).
The Pyramid API is *more* flexible than what you want, despite claiming that it is less flexible. It is all a matter of perspective but the API itself is less constraining than you want. It's clear from your requirements that you should be implementing your own internal extensions to the ISession because Pyramid has no intention of dictating things like cookie values for usage outside of Pyramid. That is the exact reason that these hooks exist. On Wed, Apr 30, 2014 at 2:29 PM, Jonathan Vanasco <[email protected]>wrote: > 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. > -- 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.
