On 04/30/2014 03:29 PM, Jonathan Vanasco wrote:
The focus of this discussion shouldn't be the merits, drawbacks, or
implementation details of server-side sessions vs client-side sessions
-- which everyone is quick to chime in on. We can talk about that all
day. We have, many times..
My concern isn't that there is a session_id variable in every session or
the uniqueness of said id.
My concern is that there should be standard way in which Pyramid plugins
use and expose the raw session_id of server side sessions. Because
ISession doesn't have a session_id , everyone has implemented this
differently. Without some sort of official stance, everyone in the
future will implement this differently. A consensus on this would allow
for server-side session libraries to be swappable -- switching from
Redis to Memcached; or "pyramid_redis_a" to "pyramd_redis_b".
I understand that "client side sessions" are "basic enough". However,
server-side sessions all rely on a raw cookie value as their session id.
It's a technological given. My concern isn't on the merits of
whether or not that ID should be trusted, if it is valuable, or what it
should be used for. My concern is the lack of a standard in the
pyramid ecosystem for dealing with this common situation.
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.
As a thought experiment, let's imagine that Pyramid cookie based
sessions did have a session id (probably just a random one), and we
changed the ISession interface to require that all sessioning
implementations exposed the session id as session.id, and that we
mandated that a session id must be a string.
Some of the proposed solutions wouldn't solve our needs, because they
stash a unique ID within the session. That solves a completely
different problem. Placing a UID/UUID within the session data works
perfectly for accessing and utilizing a UUID for a session within
python. But one must use a specific session library to load and extract
that identifier from the session payload. That's not what I'm
interested in. This internal UID is not available on the proxy/gateway
server nor is it available on nginx/apache, mod_security, other server
plugins or various other server systems that touch our http traffic.
Those can only access the raw plaintext cookie value. The internal
uuid is not necessarily available to python outside of Pyramid either,
unless one goes so far as to create a middleware package to offer it
onto other sections of the WSGI stack. I am interested in the raw
cookie value, which appears across all the various systems in our
technology stack and is used as the key in the datastore ( or can be
computed to derive that key ).
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.
Also in the "utility" column -- when dealing with "realtime" performance
logging systems like Cube / StatsD, we use the SessionID to give us
transparency across every element in our stack. Everything can access
it, so everything can log based on it. We also insert a uuid into the
header on the gateway to serve as a "request_id". session data is often
more useful than request data though. Usually you don't want to use
"highly unique" values for StatsD, but we discovered a handful of
use-cases for using the SessionID to identify bad behavior, or track
session activity within a subset of URL paths.
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?
To close out a few sidenotes:
- I thought i was clear that I was talking specifically about Server
Side sessions, not client side ones.
- I am fully aware that Client Side sessions do not have a ID. I'm not
advocating that they offer an id or should offer an id. I am advocating
for a
unified session_id interface for server side sessions.
- When it comes to server side sessions, virtually every framework has a
documented "session_id" variable OR a general consensus on what to use
when developing Plugins.
- Flasl does use signed cookies by default. BUT there is an extensive
section on the docs for Server Side Session support. All the server
side sessions examples in the Flask documentation use .sid (
http://flask.pocoo.org/snippets/category/sessions/ )
- I based my tornado comment by going through the sourcecode of multiple
session libraries from the Tornado wiki.
- Bert's session package is great, but also illustrates this issue. He
made an arbitrary decision to use `_session_id`. Packages released
under his system would be largely compatibile with one another; but
since there is no official implementation from pyramid, the session_id
should be expected to NOT be compatible with other pyramid session
packages.
--
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
--
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.
