On May 5, 2014 6:00 PM, "Chris McDonough" <[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"
(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 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.

Reply via email to