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.
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.
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.
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())
I'd consider doing that if it actually solved a concrete problem that
someone has already run into.
- 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 [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.
