On 05/07/2014 02:26 PM, Jonathan Vanasco wrote:
which is why I keep badgering him to weigh in on this issue only.sorry, i feel a bit clearer on what you want to hear now. for this particular need, the others tabled, it's largely testing and troubleshooting -- and it is a bit more advanced. things we've used that key for in the past and present: - unit and integrated tests that handle how session data is stored / persisted. ensuring it is saved across requests on the backend store and validating the backend store directly. it's a silly thing on one machine, but when you have a cluster of machines and start experimenting with Master/Slave replication, issues come up. without exposing this identifier, one needs to trust some unseen "magic" that everything is being persisted correctly, and then do subsequent requests to see if data is being pulled out correctly. i can't easily save a session and confirm how it has saved on memcached/redis ; I need to save a session and then load the session on a new request. - this also simplifies tests that ensure we have loaded the correct session or unloaded/create a "new" one. the boolean 'new' loses utility if you invalidate/create multiple sessions in a single request. chris' suggested `get_session_uuid` would handle this. - this use case borders on a tabled discussion, but accessing the session_id allows us to more easily identify and load particular sessions, and create test cases around them. for example, we may deploy some new code that stores/handles particular bits of session data differently... and that has broken some routes in the past. by knowing the session_id, we can alter the actual backend data store to create "broken" sessions in the backend, and then use unit-tests / TDD to handle the issues gracefully. - admin / troubleshooting / support - being able to identify the internal id on a first request, so it can be cross-loaded into other requests ( not as a session, but as a raw data-stash pull ); we also have exception tweens that automatically log the exceptions, session_id and a snapshot for later examination. while an internal UUID can be logged , it can't be reliably used to 'load' data off the backend (session backends aren't necessarily full-text searchable; many are k/v pairs )
All of the above use cases presume that you have visibility into the session implementation's backend to load data. If you do, that's fine, but there are no APIs in Pyramid that provide this functionality, so you're already in implementation-dependent mode when trying to satisfy any of them. Having the ability to uniformly access a session's id across ISession implementations buys you very little in these cases, because you're already relying on implementation details that necessarily go behind the back of ISession. You couldn't just swap out one sessioning implementation for another, and expect these kinds of tests or features to continue working, even if ISession did have an ID API, right?
It seems to me that the id is least of your worries in each case, or at least it would be a lot simpler to just depend on a custom concrete ISession implementation than it would be to churn the gears to mandate that all session implementations expose an id attribute. I say this because, presuming we did mandate that, you'd still have a heck of a lot of work to do if you wanted to switch sessioning implementations in midstream to make those tests pass and features work.
the other things we've used it for can be replaced by an "internal uuid" or a secondary cookie which is used as tracking identifier; however that does create the need to duplicate work and increase the amount of cookies or cookie storage. being able to access the session_id allows for a lot of savings in workload and transmission -- but the big utility is in being able to log and confirm where data is saved to.
Server-side sessions are usually quite expensive. Personally I use them very sparingly. Unleash "ab" against a page that accesses session data and see. Definitely if all I needed was some tracking identifier, I'd use a plain old cookie, if only to reduce CPU cycles on the server side. If you mean "I want to parse the session id out of the session cookie" and not necessarily "I want to access the session", I'll note again that the way cookies are composed is an detail of each ISession implementation, so simply mandating that sessions have an ID attribute doesn't buy you anything.
also, just to re-iterate, i'd be fine if this particular request weren't a "requirement" but a "suggested implementation". if ISession doesn't support it natively, fine. BUT if people build plugins that use an internal session key , there should be an official/recommended method on how to expose it. sort of like dirty-needle programs for drug addicts: if you're going to do it, do it this way. however - I don't think the potential drawbacks of the 'may return None' situation is substantial. i can only see it being an issue in two scenarios : a_ the cookie is client side b_ the plugin hasn't supported the session_key yet. There could be others, but those are the only ones i see.
I already wrote details of a scenario where a None (optional) session id is suboptimal in a prior email in this thread.
if the cooke is client side, there is no session_key. the programmer should never have accessed session_key. if a session_id is needed, docs could instruct the usage of 'get_uuid' or creating an ancillary tracking cookie. if the plugin hasn't supported the session_key yet, then - 1) there aren't many open source pyramid session packages. patches and update to 90% would be relatively quick. 2) if there is a private session package, the developer would be calling a function that they haven't provided for yet. @Randall-- for your use-case, I would probably use something like chris' suggestion -- where you have a set/get uuid function that accepts an explicit session. we run 2 sessions simultaneously -- the normal `request.session` (which is an encrypted client-based-session) and a `request.session_https` that implements a server-side session locked down to https traffic ( it's just pyramid_beaker forked and bound to SSL and a different request attribute ). we have code that operates on specific request attributes, but also other code that accepts and explicit session object. if you have the potential for conflicts
In any case, without an actual in-the-wild use description of a required feature that does not presume visibility into the session data backing store or being able to parse the session id value out of a cookie, I'm becoming more convinced that not requiring that an ISession implementer expose the session id uniformly is actually correct. That doesn't mean that session implementations can't expose it; pyramid_redis_session sessions already expose the session id (as session.session_id, FWIW), so you could rely on this implementation detail as easily as you're already relying on the detail (at least if you use pyramid_redis_sessions) that session data gets stored in redis. Relying on this would be no worse than writing integration tests that check redis to see if the data actually winds up there.
- C -- 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.
