On Mon, May 5, 2014 at 8:30 PM, Chris McDonough <[email protected]> wrote:
> On 05/05/2014 10:36 PM, Randall Leeds wrote: > >> On May 5, 2014 6:00 PM, "Chris McDonough" <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > >> > This conversation seems to be going in circles a bit. >> > >> > Rather than debating the idea in the abstract, I'm trying to figure >> out how you, in particular, would actually concretely make use of >> "session.id <http://session.id>" (or session.key or whatever). >> >> > >> > This question needs to be considered independently from: >> > >> > - being able to parse the key out of a cookie value "by hand". This >> > is unrelated to having an API on the session object itself. >> > Being able to do this is another topic which we need to >> > consider independently. >> > >> > - being able to use the key as a lookup value into a sessioning >> > implementation. There is currently no ISession API to pass the key >> > to obtain information about the session, and adding such an >> > API is yet another topic. >> > >> > Can anyone give me a concrete usage that's not solved by using a UUID >> key stored in the session data itself that does not involve the 2 >> constraints above? >> >> I've been trying and the issue is that any such scenario is just about >> configuration. >> >> For instance, if I were going to build some analytics module that >> shipped data off to be indexed I might include a session id. If I were >> to publish this as a package today I might use a setting to configure >> the key of this value in the session data. I would probably use a >> setdefault call with a uuid in a NewRequest subscriber. >> >> But as soon as we have more than one such need, I'd be configuring each >> one and each one must implement this configuration code. >> >> So the issue comes to when there is >1 included pyramid plugin that >> wants to uniquely identify the session without adding more items that >> strictly necessary. >> >> My resistance to jumping in completely on the side of adding API has >> been that I don't like making anyone deal with a maybe-None return value >> and I don't like causing extra items to be stored in the session (cookie >> storage, in particular, should be kept small). >> >> But this seems quite parallel to csrf token. >> >> I would ask, if you were to redesign it today, would your ideal ISession >> interface have csrf methods or would you want all the code that uses it >> to check for _csrf_ key in the session and create a random one if it >> doesn't exist? >> >> I imagine things like the check_csrf_token predicate would have an >> additional keyword for key were it not for an ISession API which makes >> it opaque. >> > > You're right. If I redesigned it, I might consider requiring that > ISession expose an get_uuid API which, under the hood, returned a UUID > associated with the session. It would mean satisfying your suggested > requirement that there be only one preferred way to do it for add-on code. > I would particularly use a time machine to so if I thought it would > satisfy Mike's and Jonathan's requirements. I don't think it does though, > because this API would not necessarily return the "internal" session id, > which is the key that the sessioning implementation actually uses to look > up the data. We keep hearing about needing access to the "internal" > session id from Jonathan at least, so there's more going on there, and this > seems to not be helpful for him, which is why I keep badgering him to weigh > in on this issue only. > Gotcha. I'm curious as well. > > At this point, though, I don't think I'm liable to add it retroactively, > because it would mean that existing ISession implementations would fall out > of compliance. > Fair point. > > Note that there is no requirement currently that get_csrf_token store the > token as "_csrft_" in the session itself (or that the *_flash methods > store "_f_*" tokens). That's what the cookie-based implementation does, > but it's totally up to the ISession implementer as to what they actually > do, by design. > That was rather my point. > > One compromise would be to add this function to pyramid.session: > > def get_session_uuid(session): > """ Return the uuid associated with this session """ > return session.setdefault('_uuid_', uuid4()) > > Seems reasonable, but my first thought would be (request) and I could see it having a similar progression as pyramid.security.{authenticated_user,effective_principals}, moving to deprecation in favor of a request method. Maybe symmetry with security/auth is not a useful guide here, though. Clearly, a sane migration path would be needed, and you'd want to aim for consistency in APIs, whatever that means to you. > I'd consider doing that if it actually solved a concrete problem that > someone has already run into. +1 I'll bow out because I haven't one of my own. Only hypothetical ones. -- 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.
