On Thursday, May 8, 2014 8:08:37 PM UTC-4, Chris McDonough wrote: > > On 05/08/2014 04:42 PM, Jonathan Vanasco wrote: >
> I understand this to mean (from your earlier emails, you don't expressly > say it above) that you want to be sure that there is a existing session > that has the id "123" if you parse "123" out of the cookie. Since we > can't stop browsers from sending cookie data, and since sessions have a > timeout (and as a result even a valid session id might not resolve to a > non-new session), I don't see how it would be possible to make that > promise due to the way the web works. The only implementation that > would have a shot at it would be purely cookie-value-based sessions, > because the value is stored in the cookie itself. > No. My desire is to associate the session to an incoming value so that I can do things like - have full transparency on how / why the session is created - replay requests during troubleshooting - simplify integrated tests that involve cookie data deriving session_ids and other stuff out of a cookie value is possible, but not guaranteed. while i could easily do it with current session libraries, i can't and rely on that. as i explained above, and showed in a gist, there is no direct connection between a Session and the cookie it is related to ( or other possible 'public identifier' ). In the case of cookies, this value could exist on the Request or Response object (server side cookie) and request object (client side cookie). i can assume that a "not new" session should correlate to an incoming cookie; and a "new" session should correlate to an outgoing cookie. however there is no certainty here; it's an assumption. being able to associate an input with a session is largely understanding an implementation detail. i am not concerned with the data serialized inside the cookie, or associated to it via a backend store ( directly or though a cookie encoded value ). i'm just concerned with being able to correlate an input value (cookie) to a session and vice-vesra. I also understand that developers will care deeply about a return value; however they shouldn't be expecting/caring for one that doesn't exist by virtue of their choice in session stores. I'm not disagreeing with your assessment, I just see it more like a paradox. In any case, wrt black box magic, I'm sure you understand that the point > of an interface is to create a black box, such that one box can be > swapped for another by otherwise unconcerned consumers without the > consumer needing to open either box. Once you start dithering in the > interface definition about what's expected of implementations, it's > understandable that those implementations aren't going to be able to > satisfy the intent of the interface. Yes, but there is a divide between systems that operate with "total magic" and keep most things away from developers ( Django, Rails) and systems that don't hide the underpinnings ( Pylons, Pyramid). The way that Pyramid functions -- which extends beyond the ISession interface -- sessions are a black box. They sort of magically work -- which is great -- but you can't access any of the HOW or WHY unless you write custom session implementations. If the argument, instead, was "I want to be able to load session data using > an arbitrary session id via a well-defined interface so I don't have to go > look at any implementation details", I'd understand. But nobody has asked > for that so far. Is it because it seems like a bridge too far, or what? Personally, I'd love to have something work like that. An ISessionLoader or similar. It would make testing so much easier, as we do that already :) But if there is a huge debate over getting just ID, it doesn't seem worth bringing up. > FWIW, this means that each request, even one for a static resource like an image or a JS file, is potentially creating a (or at least deserializing an existing) session object. This is almost sure to be a bottleneck and may be slowing down your app by an order of magnitude or two. Deferring until the session is accessed via its factory (when request.session is accessed) prevents this from happening, so it's probably better to do it that way. Only dynamic content hits Pyramid in our stack; nginx/varnish catches the rest. Sessions are hit on every page to pull out "is_logged_in" and other data. Since most data got moved into a read-through cache, our biggest bottlenecks are actually template rendering (!). > When you say "how the key is being managed", you mean figuring out what attribute of the session that the key into the backing store is being set into? Does this actually take a lot of time as compared to all the time it takes to figure out how the session machinery stores its data so you can yank it out later? Actually, yes. The data serialization tends to be straightforward. It usually takes a couple seconds to identify. It's often simple. The session key stuff tends to be harder to find, as the "raw" id goes by different names and can be somehow encoded. We do a lot more tracking with the raw key than the tracked session data though. -- 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.
