On Apr 28, 2014, at 21:28 , Mike Orr <sluggos...@gmail.com> wrote: > On Mon, Apr 28, 2014 at 3:07 PM, Chris McDonough <chr...@plope.com> wrote: >> On 04/28/2014 04:05 PM, Jonathan Vanasco wrote: >>> >> IMO, the point of an interface is to provide an abstract API which folks can >> meet to provide alternate implementations. If server-side session >> implementations had a session id, but client-side session implementations >> did not, it would mean that *deployers* of an application could not switch >> out the sessioning implementation from one to the other and still expect the >> parts of their applications which rely on sessions to work, which is AFAICT >> exactly what you're objecting to now. > > We don't need two interfaces. We just need an interface that says > 'session.id' or 'session.get_session_id()' should return the session > ID string, or None if it doesn't support session IDs or doesn't wish > to expose it. Presto, everybody's problem is solved. > >> The only difference between this >> scenario and the one you're objecting to is that you started relying on >> something *outside* the interface, and when you changed to using something >> that actually complied with it, you got hosed. > > I switched from Pylons to Pyramid and got hosed. Pyramid is supposed > to be better than Pylons and more flexible, but in this case it's > worse and less flexible. > > The Pyramid interface is less useful than Beaker's. That's a > limitation of the Pyramid interface, and can arguably be considered a > bug. > >> In the meantime, AFAICT, it's reasonably simple to put a random id (or >> ... in the session >> dict. This would make the application run under any sessioning >> implementation. > > That's what I ended up doing, but why not have a standard way to get > the session ID? > >>> client-side sessions don't have an id, but server-side sessions require >>> it. because pyramid doesn't have an official interface to support this, >>> all server side session libraries need to implement this themselves -- >>> somehow -- to support it. I stress "somehow". There's no way to ensure >>> or expect consistency in this across libraries. If you look at how >>> different session providers in the ecosystem have dealt with this, there >>> is little uniformity in approach. I've seen `session_id`, >>> `_session_id`, `sessionID` and a few other variations -- both as >>> attributes and internal dict values. If ISession had an official >>> `session_id` attribute, then people developing server side libraries >>> would adapt to that; there would be uniformity and portability. Those >>> using client-side sessions would never use or expect a session_id , and >>> not be inconvenienced. > > I *tried* to write a 'pyramid_[session]' library... > > I *tried* to modify 'pyramid_redis_sessions' to put the ID as > 'session.id' or 'session["id"]''... > > I *tried* to understand how Beaker did it... > > But every time I got lost in how they generate the ID and manage the > cookie. And when I tried to just read the cookie in my tween, I > realized I would have to unsign it and get the secret... all the stuff > that the session library does, and why should I have to reimplement it > all? Why can't the library just have a METHOD that I can CALL? > Everything else in Pyramid does. >
What are you using the session ID for? Bert JW Regeer
smime.p7s
Description: S/MIME cryptographic signature
