CherryPy: URL-basierte Sessions

[Qubit]

Habe heute abend angefangen, mich mit CherryPy zu beschäftigen (Version 3.1.1 via mod_wsgi hinterm Apache).
Leider ünterstützt es imho nur Cookie-basierte Sessions, das gefällt mir nicht so
Daher kurzerhand ein "Hack" für URL-basierte Sessions:
/lib/sessions.py (ab Zeile: 619)

Code: Alles auswählen

    # Check if request came with a session ID
    id = None
    if name in request.cookie:
        id = request.cookie[name].value

    ### url session hack ###
    id = request.params.get(name,id)
    ###

    # Find the storage class and call setup (first time only).

Edit: optimiert

So ein "Patch" ist natürlich unschön, aber ich sehe keinen "Hook" oder Möglichkeit für ein "Tool".
Meine Frage daher an die Profis:

Kann man URL-basierte Sessions "schöner" implementieren, d.h. "generischer"?

[Y0Gi]

Darf ich kurz zwischenfragen, warum du GET-Session-Identifier besser findest? Die müllen Logfiles zu, sorgen für unschöne Links und können Session-Hijacking erlauben, insbesondere wenn unbedarfte Benutzer solche Links weitergeben.

[Qubit]

Darf ich kurz zwischenfragen, warum du GET-Session-Identifier besser findest? Die müllen Logfiles zu, sorgen für unschöne Links und können Session-Hijacking erlauben, insbesondere wenn unbedarfte Benutzer solche Links weitergeben.

??? ist zwar ein anderer Thread, aber..
Ich filter meine Logfiles, du nicht? Hijacking ist auch mit Cookies möglich und Session IDs werden dort verwendet, wo sie nötig sind, d.h. man kann Webressourcen allgemein auch ohne Query-String verlinken (man muss sich nur dann authentifizieren) oder man macht durch ein internes Rewrite den URL SEO freundlich.

Cookie sind kein Allheilmittel und viele deaktivieren sie browserseitig (Stw. Cross Site Tracking, bei dem man Webressourcen gegenseitig verlinkt: Zb Werbebanner auf bild.de und playboy.de. Das Cookie vom Bannerserver verrät diesem, dass du beide besucht hast. Lustig: Datenschutzrichtlinie im IE7 auf "hoch" und Cookies von bild.de werden geblockt, aber nicht vom Bannerserver ) Oder das Expire (maximum age) der Cookies kann von der Zeitdifferenz zwischen Client und Server abhängen, etc.

Bei "mission critical" Sachen verwende ich im übrigen neben SID noch Transaktions-IDs (TID), die sich dynamisch mit jedem Response ändern und darüberhinaus Ressourcen abhängig sind. Sie werden dynamisch via Javascript vom Server geholt.

Also der "Freiheit" willen, warum keine URL basierte Sessions? Das sollte jeder selbst entscheiden können