On Apr 29, 2014, at 14:30 , Jonathan Vanasco <jonat...@findmeon.com> wrote:
> On Monday, April 28, 2014 11:46:22 PM UTC-4, Bert JW Regeer wrote: > What are you using the session ID for? > > Performance logging (session_id into statsd and logs). Unit Testing. > Integrated Testing. Automated Test suites. Development Troubleshooting ; > Production Customer support. I would say you are dual purposing the session ID. There is no guarantee that for example the session id is always unique within a certain timeframe. If one session ends, it is technically possible for a new session to be created with the same ID. Using it for logging, or any of the above seems like it would be setting yourself up for failure, or more log hunting than necessary. If you need a unique identification, add it to the session yourself. request.session[‘unique_id’] = uuid.uuid4(). Do note that even Django has changed the session_key from session.session_key to session._session_key. Note that Python convention states: _single_leading_underscore: weak "internal use" indicator. Add the unique id, and problem is solved. This would solve it across the board, even on those session implementations that would return None (as suggested previously in this thread). > > Often times we need the actual SessionID, which is used as the storage backed > identifier, to access the stored value. It's annoyingly complicated to > working around this with custom classes and monkeypatches for each > session-ing option. Certain session implementations there is no storage backing it, such as the cookie only, in that case having a session id is completely useless, since it isn’t used. There is no way to retrieve the session information because it isn’t stored server side. > > Beyond that, I can't make this clear enough... Personal opinions on > Interfaces / Client vs Server / etc aside... I'd like to talk about common > expectations : > > 1. Server Side Sessions are historically common across the internet. Server > Side Sessions are basically how shit got done for decades. Developers expect > them. Jump on StackOverflow and you'll see thousands of questions across a > variety of languages for people talking specifically about the session_id. Yes, and a lot of those answers actually are: “Sorry, that isn’t possible, add in your own unique identifier”. See: http://stackoverflow.com/a/15187430/13986 (Flask session id) > > 2. How other popular python projects deal with session ids: > > Beaker Session > ( used in Bottle, Turbogears, Pylons ) > .id > > Cherrrypy > .id > > Django: > old - request.session.session_key > new - request.session._session_key > > Flask: > .sid Flask, also uses signed cookies, see: https://github.com/mitsuhiko/flask/blob/master/flask/sessions.py there is no .sid variable available to get access to the session ID. The only .sid I can find is in one particular implementation of a file backed session manager, which is an implementation detail. It is not part of the official Flask session support. > > plone > getBrowserId() > > tornado > no standardized session support > multiple endorsed addons provide session support , all seem to > provide id but differently > Tornado as you stated doesn’t have any session libraries out of the box, and thus it is strictly implementation defined. When using secure cookies with tornado however no session ID is provided. > web2py > response.session_id If you are using the cookie based session storage, response.session_id will be True for every single last session: https://github.com/web2py/web2py/blob/7592cd2fe031509446042d5c768c90116ebfaf9c/gluon/globals.py#L803 In other words, not exactly something to rely on, and definitely not something used for logging. Once again, session id existing and being useful is implementation defined. > > werkzeug > .sid Werkzeug has no default session implementation. There are two implementations that can equally be used for storing session information. The contrib/sessions.py or the contrib/securecookies.py. The latter does not provide a session ID. > > web.py > .session_id > > webapp2 > .sid > This depends on the backend being used. If you use the default secure cookie storage, there is no session ID available. https://code.google.com/p/webapp-improved/source/browse/webapp2_extras/sessions.py#177 > zope: > externally getClientId > internally client_id > I didn’t care to go digging into the Zope source tree... > > Pyramid appears to be the ONE AND ONLY python web framework that supports > sessions BUT does not support a session_id. In fact, as stated above, the > core developers oppose supporting a session id. Pyramid is not the only one that doesn’t support session ID’s, as proven above. Many of the above implementations use the secure cookie method that Pyramid is also using, and with the exception of Beaker (they are generated and then stored as data within the session itself), do not provide a session ID when using the secure cookie method. Even with the server side storage ones, depending on the implementation the session ID may or may not be available, just like in Pyramid it is implementation defined based upon the current session provider being used. Relying on the session ID being available (especially in web2py…) is simply not a good idea. It is a much better idea to store a unique value into the session yourself. > > I don't mean to disagree or address any of the rationales/reasons mentioned > above against supporting the session id. Many of them are very good and > sound. > > However, if you want to know why this question comes up often , why it will > continue to come up often and -- potentially -- why some people might be > turned off by pyramid... it's the list above. What is simple, normal, > expected, trivial and standard across many frameworks is an "advanced topic" > in Pyramid and left to developers to deal with on a per-project basis. > Pyramid is the least opinionated framework for just about everything -- but > sessions. Except as I have just proven that this is’t normal, expected or trivial and standard across many frameworks. The session ID existing isn’t a guarantee by a long shot. Add a NewRequest handler that fires, have it check the session for your unique ID, and if it doesn’t exist, add it to the session. Or add a new reified method to request that checks the session for this unique ID, and if it doesn’t exist create one and set it in the session, and return it. Then request.unique_id will return that sessions unique ID, that can be used for logging. This isn’t an advanced topic in Pyramid, and I would argue it isn’t even a limitation. There are many solutions all of them equally simple to implement. My pyramid_pluggable_session allows you to very simple plug in new backends, and has a _session_id available on it, start using it across all your applications and you will have access to a session id that is unique. It’s unlikely there will be a collision in 20 bytes of random anytime soon. With sessions Pyramid is also not opinionated. Out of the box it provides a very sane default, and users are encouraged to find other session implementations that match their needs. The ISession interface contains everything required, application developers can layer any other functionality required on top to customise sessions to their needs/requirements for their application. Build a vanasco_sessions module, upload it to pypi and depend on it in all your future Pyramid applications. Now you can always be guaranteed that a session ID variable exists in your session. Bert JW Regeer
smime.p7s
Description: S/MIME cryptographic signature
