On Wednesday, April 30, 2014 4:28:49 PM UTC-4, Chris McDonough wrote:
>
>
> By the way, thank you for keeping up with this discussion, I know
> debating about things with folks who don't share your point of view can
> get pretty boring and frustrating.
>
Thanks, and right back at you on both points. I know and admit that I am
the taxing and annoying person here!
My rationale for all this argument isn't for my benefit. whenever i use
pyramid I can (and do) write in my needed functionality. i can
patch/fork/subclass in most needed functionality. i just worry because
this is still a common situation and common need. with a bit of leadership
-- even if only in documentation -- the pyramid ecosystem would get a lot
more interoperability and avoid problems with newer devs.
Next to that...
Correct on all things that you and Mike noted :
1. Sessions might not have a cookie - they could be implemented with a URL
fragment. That was popular years ago, when browsers might not support
cookies and developers didn't worry as much about the effect of URL
elements on search engines or browser security (the url is often logged ,
headers are not).
2.Some sessions schemes do have 2 session identifiers :
a) a public session_id , transmitted in plaintext and typically used in
cookies
b) a private session_id , a value computed from the public session_id,
which is mapped to a backend storage.
The standard beaker cookie is actually a concatenation of a digest + the
session id for some lightweight validation. The underlying session_id is
in plaintext within the cookie, but it's prefixed by some other data.
There are a handful of dual-key implementations that encode the underlying
session id. most often the public session_id is just the backend
identifier that has either been encrypted or digitally signed (with an
expiry time, ip address, etc). these patterns are less like the classic
Server Side Session pattern and more like a Client Side Session pattern
with a backend payload identifier. In the case above the payload is a
server side session id; but often times it's an internal "user id" or other
data used to sync logged-in activities across devices by the same user.
now let me respond to these 2 notes you made :
> The presumption that there is a session.id variable won't solve this
> particular problem, as Bert and Mike have already said. But as a
> separate problem, it could be "solved" if we mandated that a session id
> be made available in a common way in the cookie that represents the
> session token across all implementations. This is a big ask, though, if
> only because it means that folks who don't actually want to expose the
> raw session id could not create an interface-compliant implementation.
> In my experience, it also generally makes systems less flexible when you
> begin to tell potential implementers how they must do things rather than
> only telling them what they must do.
> .....
Would the addition of session.id help here or does your stack have the
> same problem where the session id must be discoverable outside Pyramid?
>
Let's assume that I have a plaintext session id in the cookie , named
"SessionID".
When I'm looking throughout the stack for the current SessionID, I can just
look at the header value which is associated with the incoming GET/POST
request. Great.
When I'm in Pyramid I can look at the incoming cookies but... here's the
annoying part... that cookie may or may not belong to the current session.
The SessionID on the incoming session may have been invalidated by an
underlying timeout, ip mismatch, backend cache miss; or even a developer
calling 'invalidate'. The cookie value for the new, current session,
would be in the response object.
because of this behavior (which is good), one needs to search in multiple
places in order to find the cookie associated with the current session.
here's a sample gist...
https://gist.github.com/jvanasco/aa6a844ee5f27d37f588
after going through this dialog and example, i think i can better state the
frustration / what I think the shortcoming is, and in a way that applies to
client and server based sessions alike...
The issue is not really about deriving the underlying session_id, which may
or may not be encoded. Though it would be great if that existed. This is
perhaps a side-topic.
The issue is in not having a direct association between a "session object"
and the "cookie value" which created it.
A client-side session would always correspond to the incoming cookie value.
A server-side session could be associated with a cookie value that appears
in either the request or response cookies -- or neither in the case of
multiple invalidations.
There's simply nothing that ties the originating cookie value to a given
session object.
--
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.
