On 05/02/2014 03:42 PM, Jonathan Vanasco wrote:
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.
Sure. It's always a tradeoff, though. If we over-specify the session
interface, it makes session implementers' lives harder, and may reduce
flexibility for consumers.
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).
Not a fragment (these are never sent to the server), but yeah, a URL
segment or query string.
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.
Yes, lots of strategies to ensure that the session id being sent is valid.
now let me respond to these 2 notes you made :
The presumption that there is a session.id <http://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 <http://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".
I'd rather assume you didn't, at least for purposes of answering the
second question above. As I'm sure you know, being able to parse the
session id out of a raw cookie value is definitely distinct from being
able to access the session's id as "session.id", and in the spirit of
the history of this thread, and the passion put forth in arguments for
the it, I'm at this point really just trying to figure out whether
there's benefit to mandating that ISession implementers must supply an
ID available as "session.id". In the interest of being clear, we should
settle that first.
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.
Let's similarly put this third topic on the backburner while we figure
out whether it would benefit you to have a "session.id" attribute common
to all session implementations.
- 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 pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
