On Apr 30, 2014, at 13:29 , Jonathan Vanasco <jonat...@findmeon.com> wrote:
> […] > This seems to be going in circles. session id is not common across all implementations, doesn’t need to exist for most of them, and thus shouldn’t be relied on. Instead stick your own unique token into the session if you want it. You haven’t convinced me that session_id should be added to the ISession interface. > The desired "session_id" logging gives parity from our Python logs to our > webserver logging -- which can only access raw header/cookie values. Third > party analytics systems, driven by PHP's popularity, expect to see this and > will segment on the logged session-id. Even with my session library, which offers a session ID, you can’t just pull the session ID out of the cookie since it is JSON serialized and signed. The cookie is of no use what so ever for tracking. Even on PHP systems if one for example has PHP SuHoSin installed the session cookie is automatically securely signed/encrypted. Once again, the web server has no access to the session id. If you want to track a request from front-end to backend add another HTTP header that gets logged on the front-end/back-end. Just like Cloudflare does with their CF Ray ID header. Then you can track web server hits to backend hits without relying on an implementation specific cookie value! Note once again that the cookie contents for a particular session are implementation defined, there is no standard across them at all! > > […] > > - 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. That is why it has an underscore prepended, this makes it an internal value that can not be relied on, unless you always use my session package. The nice thing is that with mine you can keep using it, as long as you swap out the plugs, and they won’t ever alter the fact that there is a _session_id. Unless your session cookie (sent to the browser) is just the session ID, without signing (which allows users to trivially change the session ID associated with their connection, which is bad juju if you don’t want them trying to gain access to an administrative session for example by iterating over session id’s), the session cookie will never contain just the session id. Thus using that to track requests across web server to back-end doesn’t make sense either. Bert
smime.p7s
Description: S/MIME cryptographic signature
