Erfahrungsbericht: CherryPy und Cheetah

Gute Links und Tutorials könnt ihr hier posten.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 29. Mai 2007, 23:46

Hallo!

Ich befasse mich derzeit mit der Einarbeitung in CherryPy und in Cheetah. CherryPy ist ein Anwendungsserver für Webanwendungen und Cheetah ist eine Vorlagensprache.

Meine Gedanken dazu habe ich in einem Erfahrungsbericht zu Papier (äh... zu Wiki) gebracht und werde diesen auch noch um ein paar Punkte erweitern.

Es ist jetzt schon mal so weit, dass das Geschriebene einen Sinn ergibt. Es fehlt zwar noch ein Beispiel mit mehreren Ordnern und Dateien und die Integration in den Apachen, aber ich denke, als kleine Einführung könnte der Erfahrungsbericht schon mal durchgehen.

http://halvar.at/python/cherrypy_cheetah/

Viel Spaß beim Ausprobieren.

lg
Gerold
:-)

PS: Wenn du Verbesserungsvorschläge hast, dann raus damit. ;-)

Edit: URL ausgebessert
Zuletzt geändert von gerold am Dienstag 4. Dezember 2007, 20:44, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 30. Mai 2007, 13:23

gerold: Sehr schön.

Darf ich fragen, ob du dir Genshi angesehen hast und was dir daran speziell gefehlt hat? Gerade durch deinen ZPT-Hintergrund wäre dessen elegante Attribut-Syntax für dich wohl am naheliegensten gewesen. Und über Match-Elemente und die XIncludes bin ich persönlich ausreichend in der Lage, Macros und Wiederverwendbarkeit zu nutzen.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 30. Mai 2007, 14:19

Zuerst hatte ich mich in das Tutorial von Django eingearbeitet, aber mich interessiert die Arbeit mit Datenbankabstraktionsebenen (Objektrelationale Mapper) nicht. Die verbergen mir zu viel von dem was eine gute Datenbank kann. Außerdem kann ich SQL ziemlich gut und habe gelernt, damit meine Probleme zu lösen. Ich frage mich wirklich, warum das Tutorial von Django sich so sehr mit Datenbanken beschäftigt. Dann kommt noch dazu, dass beim Erstellen einer Django-Anwendung gleich auch noch eine Administrations-Website erstellt wird, mit der ich auch Zugriff auf Datenbanken habe???
Zu django: Du kannst auch RAW-SQL Statements absetzten. Also alles das machen, was du auch mit der Python DB-API machen kannst. Wie das geht steht hier: http://www.djangoproject.com/documentat ... custom-sql

Das Admin-Panel musst du nicht nutzten, wenn du nicht willst. Dazu brauchst du nur in deiner settings.py den tupel Eintrag in der INSTALLED_APPS Variable zu löschen. Genau so kann man auch andere Teile von django "abschalten"...
Wenn man allerdings alle netten Features von django abschaltet, macht es wohl aber kein Sinn überhaupt django zu verwenden.

IMHO muß man sich auch erstmal unvoreingenommen mit den django Features auseinander setzten, bevor man sie einfach abschaltet. Denn viele Dinge sind sehr praktisch.
So kann hat man mit dem Admin-Panel einen sehr praktische Möglichkeit Daten in der DB zu ändern, ohne dabei z.B. auf phpMyAdmin zurück greifen zu müssen und das out-of-the-box!

Wenn man bei seinen Modellen noch in paar Meta-Informationen zum Aussehen des Admin-Bereichs einfügt, hat man sogar eine recht übersichtliche Eingabe Möglichkeit für seine DB Daten... So schnell bekommt man das IMHO mit keinem anderen Framework hin.

Mit newforms kann man auch super schnell ein HTML-Formular für seine Tabellen erzeugen. Das geht mit Validierung der POST Daten in ein paar Zeilen code.

django verfolgt halt wie Python selber die "Batteries Included" Philosophie. Für diejenigen die doch wieder alles selber machen wollen, ist das wohl nichts...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Mittwoch 30. Mai 2007, 16:17

Nettes Tutorial.
Da gerade CherryPy 3 in den Startlöchern steht würde mich mal interessieren, wie sich das anfühlt. Bei CherryPy 2 hat mich das Dispatching etwas gestört, weil es schon verdammt beengt. CherryPy3 soll da ja Routes Unterstützung bieten.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 30. Mai 2007, 19:31

Y0Gi hat geschrieben:Darf ich fragen, ob du dir Genshi angesehen hast und was dir daran speziell gefehlt hat?
[...]
Und über Match-Elemente und die XIncludes bin ich persönlich ausreichend in der Lage, Macros und Wiederverwendbarkeit zu nutzen.
Hallo Y0Gi!

Genshi war ziemlich weit oben in meiner Rangliste. Ich konnte mich nur nicht in die Umgekehrte Reihenfolge der Code-Wiederverwendung eindenken. Mit TAL/METAL ruft man von jeder TAL-Seite aus das Makro der Hauptseite auf und füllt "Slots" mit den geänderten Daten. Bei Genshi scheint es genau umgekehrt zu funktionieren. Man arbeitet ständig mit der Hauptvorlage und ändert die Incluces je nach anzuzeigender Seite. Zumindest wurde es mir in den paar Stunden, die ich Genshi gewidmet hatte, so vermittelt.

Ich habe auf die Schnelle kein gutes Beispiel gefunden und da es sich, wie oben schon erwähnt, (für mich) ungewohnt anfühlte, habe ich es nicht mehr weiter bedacht. Dann kommt noch dazu, dass ich mindestens schon fünf Designern/Grafikern/Freunden TAL/METAL beibringen wollt und nicht ein einziger ist mir darauf eingestiegen. (mir wäre es mit Genshi wohl kaum besser ergangen) Nur ein Kollege von mir (ein Administrator) kommt damit klar. Er hilft mir jetzt öfter mal bei Zope-Websites. Als ich letztens einem meiner Kollegen Cheetah zeigte, war alles nach ein paar Minuten klar. Sogar ``#for`` und ``#if`` wurde sofort verstanden. Ich musste nichts erklären. Es erklärte sich (fast) alles von selbst. Das ist wahrscheinlich der Grund dafür gewesen, warum ich bei Cheetah geblieben bin.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 30. Mai 2007, 19:47

jens hat geschrieben:django verfolgt halt wie Python selber die "Batteries Included" Philosophie. Für diejenigen die doch wieder alles selber machen wollen, ist das wohl nichts...
Hallo Jens!

Ich habe vor kurzem ein Plone-Projekt, an dem ich wochenlang programmiert habe, hingeschmissen. Ich weiß, das ist nicht rühmlich, aber ich hatte mich festgefahren. Ich setzte hauptsächlich Automatismen wie z.B. Archetypes ein. Das war mein Fehler. Zuerst änderte sich die API nach einem Update auf ein neueres Plone. Das konnte ich noch in den Griff bekommen. Dann musste ich für jede Kleinigkeit, die ich außerhalb des Archetypes-Frameworks anpassen wollte, geeignete Hook-Punkte finden. Und bei jeder Änderung dachte ich mir, wie leicht ich das ohne Archetypes geschafft hätte und wieviele Tage ich jetzt damit verbrachte, herauszufinden, wie ich Archetypes teilweise umgehen könne.

Ich verfluchte jede Änderung, die sich der Kunde wünschte.

Alles was ich jetzt will, ist ein Framework, das mir nur die wichtigsten Dinge wie Auslieferung der HTML-Seiten, Auslieferung der statischen Objekte, Sessions, Authentifizierung und noch vielleicht ein paar Kleinigkeiten erledigt. Alles was darüber hinaus geht, möchte ich gezielt nachinstallieren und vorher auswählen/testen können.

Ich muss zugeben, es entwickeln sich im Moment immer mehr nützliche, kleine WSGI-Komponenten, die genau eine Sache erledigen und nicht mehr. Diese Entwicklung sehe ich sehr positiv.

Um zu Django zurück zu kommen. (Gleiches gilt für Pylons.) Im Moment bin ich nicht in der Stimmung für eine Eierlegende Wollmilchsau, die ich zuerst auf Diät setzen muss, bevor sie für mich verwendbar wird. Wie du siehst ist das auch wieder nur eine Gefühlssache. Wie vieles bei mir.

Ich will mit meinem Bericht niemanden von Django, Pylons, Colubrid, oder anderen Frameworks abbringen. Ich kann nur meine Meinung vertreten -- und auch die ändert sich im Laufe der Zeit immer wieder. Wenn jemand glaubt, ich habe ein Framework zu unrecht nieder gemacht, der soll sich melden. Ich werden diesen Teil dann aus meinem Erfahrungsbericht raus schneiden. Es steht ja sowiso nur so viel drinnen, weil ich mich gerne schreiben höre. ;-)

Zwei Frameworks werde ich mir ganz sicher noch ansehen: Webware und Werkzeug.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 30. Mai 2007, 20:12

blackbird hat geschrieben:Nettes Tutorial. Da gerade CherryPy 3 in den Startlöchern steht würde mich mal interessieren, wie sich das anfühlt. Bei CherryPy 2 hat mich das Dispatching etwas gestört, weil es schon verdammt beengt.
Hallo blackbird!

Danke! Ich kenn CherryPy 2 nicht. Ich bin jetzt voll in CherryPy 3 eingestiegen.

Der Dispatcher, der standardmäßig aktiv ist, arbeitet so:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-15 -*-

import cherrypy

class Root(object):
    def index(self):
        return "Ich reagiere auf http://localhost:8080/"
    index.exposed = True
    
    def servus(self, vorname = ""):
        return "Ich reagiere auf http://localhost:8080/servus?vorname=Gerold"
    servus.exposed = True

class Unterordner1(object):
    def index(self):
        return "Ich reagiere auf http://localhost:8080/Unterordner1/"
    index.exposed = True

    def servus(self, vorname = ""):
        return "Ich reagiere auf http://localhost:8080/Unterordner1/servus?vorname=Gerold"
    servus.exposed = True

root = Root()
root.unterordner1 = Unterordner1()

cherrypy.quickstart(root)
Es gibt aber auch die Möglichkeit, "Regular Expressions" zum mappen an Objekte (Klassen, Methoden und sogar einfache Funktionen) heran zu ziehen. Es gibt mehrere Dispatcher und was viel schöner ist, eine "default"-Methode. Ist diese definiert, dann ist sie für alle Anfragen zuständig, die vom Dispatcher keinem anderen Objekt zugeordnet werden konnten. Exaktere Informationen darüber findest du hier: http://www.cherrypy.org/wiki/PageHandlers

Code: Alles auswählen

def default(self, *args, **kwargs):
    return "Ich bin für nicht zuweisbare Requests zuständig."
default.exposed = True
Ich werde mir demnächst CherryPy so anpassen, dass es beim Starten unterhalb des Programmordners nach __init__.py-Dateien sucht und diese automatisch in den "Tree" hängt. Dann werde ich mich auch noch darum kümmern, dass Vorlagen (TMPL-Dateien) automatisch befüllt werden, wenn diese über den URL aufgerufen werden. Das wäre dann so eine Art PHP-Ersatz. :-)

mfg
Gerold
:-)

PS: Sorry für die vielen untereinander stehenden Beiträge, aber ich kann nur so. Ich will die Antworten nicht in einen Beitrag zusammenfassen.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 30. Mai 2007, 23:59

gerold hat geschrieben:Ich habe vor kurzem ein Plone-Projekt, an dem ich wochenlang programmiert habe, hingeschmissen. Ich weiß, das ist nicht rühmlich, aber ich hatte mich festgefahren. Ich setzte hauptsächlich Automatismen wie z.B. Archetypes ein. Das war mein Fehler. Zuerst änderte sich die API nach einem Update auf ein neueres Plone. Das konnte ich noch in den Griff bekommen. Dann musste ich für jede Kleinigkeit, die ich außerhalb des Archetypes-Frameworks anpassen wollte, geeignete Hook-Punkte finden. Und bei jeder Änderung dachte ich mir, wie leicht ich das ohne Archetypes geschafft hätte und wieviele Tage ich jetzt damit verbrachte, herauszufinden, wie ich Archetypes teilweise umgehen könne.
Ja, sich auf APIs verlassen, die sich ändern ist natürlich sehr unpraktisch und ärgerlich, da stimme ich dir absolut zu. Aber ich muss zugeben, dass in der Zeit die ich mit Django verbracht habe sich die API nur einmal stark geändert hat (für Eingeweihte: magic-removal). Aber es ist nicht so, dass es sich von einem Moment auf den anderen verändert hat: man konnte die neue API schon vorher ausgiebig testen und es gab Wiki-Seiten auf denen die Migration haarklein beschrieben war. Im Moment sind keine wirklich großen Änderungen in Sicht und ab Version 1.0 wird die API wohl quasi fest wie Beton sein (was natürlich andererseits auch Problematisch sein kann).
Das Umgehen der Automatismen ist natürlich so eine Sache: Automatismen sind genau dann praktisch, wenn man genau das macht, was sich der Autor des Automatismus gedacht hat gedacht hat. Deswegen hat auch Rails viel Magic, viel mehr als Python-Programmierer gerne haben und man kommt damit schneller zu ergebnissen als mit Python-Frameworks. Dies macht natürlich anfänglich Eindruck bei Einsteigern, aber irgendwann merkt man, dass viele Dinge nicht so funktionieren wie man es sich wünscht.
Jedoch ganz ohne Automatismen kann und will man nicht immer auskommen. Ich finde es gut, dass meine Programmiersprache sich um den Speicher kümmert, weil der Aufwand sich darum zu kümmern wohl eher geringen nutzen hätte. Auch finde ich es angenehm, mit den Daten als Objekte arbeiten zu können, auch wenn diese Daten letztendlich nur Spalten in einem RDBMS sind. Ich habe mich letztens darüber unterhalten, dass es praktische wäre, Daten in Webapplikationen direkt als Objekte serialisieren zu können - klar, das fühlt sich sauberer an, aber ein ORM reicht Momentan auch aus, weil es eben so Dinge wie Interaktion mit dem DBMS automatisiert.
gerold hat geschrieben:Alles was ich jetzt will, ist ein Framework, das mir nur die wichtigsten Dinge wie Auslieferung der HTML-Seiten, Auslieferung der statischen Objekte, Sessions, Authentifizierung und noch vielleicht ein paar Kleinigkeiten erledigt. Alles was darüber hinaus geht, möchte ich gezielt nachinstallieren und vorher auswählen/testen können.
Ich glaube diese Größenordnung ist in WSGI-Frameworks nicht vertreten, bzw. nicht besonders gut. Es gibt Colubrid und Werkzeug die Seiten ausliefern (d.h. Request+Response), für Auslieferung der Statischen Inhalte gibt es WSGI-Anwendungen (namentlich `static`), dür Sessions (`Beaker`, `flup`, `web`, `Web Modules`, `wsgistate`, `WSGIUtils`) & Auth (`AuthKit`, `paste.auth`, `Barrel`, `web`, `Web Modules`, `wsgiauth`, `WSGIUtils`) gibt es Middlewares. Es ist ja alles da, vieles sogar mehrfach implementiert.
gerold hat geschrieben:Um zu Django zurück zu kommen. (Gleiches gilt für Pylons.) Im Moment bin ich nicht in der Stimmung für eine Eierlegende Wollmilchsau, die ich zuerst auf Diät setzen muss, bevor sie für mich verwendbar wird. Wie du siehst ist das auch wieder nur eine Gefühlssache. Wie vieles bei mir.
Für DJango trifft das zu - wenn du das nimmst, was es bietet ist es super. Willst du etwas anderes, wird es kompliziert. Das ist eben das Argument für Pylons: Pylons ist stark in WSGI integriert und kann so problemlos WSGI-Komponenten nutzen. Und wenn du Pylons nicht mehr magst, dann wirst du es los, kannst die Komponenten aber weiterhin verwenden.
gerold hat geschrieben:Zwei Frameworks werde ich mir ganz sicher noch ansehen: Webware und Werkzeug.
Ich habe mir Webware vor langer Zeit, also 2003, also 0.8.1 aktuell war angesehen (da war ich noch auf dem PSP-Trip, bevor ich festgestellt habe, dass das nicht der Weg ist, den es sich zu gehen lohnt). Das war bevor sich WSGI Webware von Webware abgespalten hat, also das was später WSGIKit wurde und nun Paste ist. Es kam mir damals kompliziert zu installieren vor und wenig benutzt. Ein Framework das nur wenige nutzen ist meiner Meinung weniger Wert als ein Framework, dass nur ich nutze, weil ich es selbst zusammengestellt habe. Andernfalls muss ich mit den Entscheidungen der Framework-Entwickler leben und bekomme kaum Support.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
fme
User
Beiträge: 34
Registriert: Sonntag 1. April 2007, 18:58
Wohnort: Bremen

Donnerstag 31. Mai 2007, 10:31

CherryPy Webpage hat geschrieben:CherryPy passes all GET and POST variables as method parameters.
It doesn't make a difference where the variables come from, how
large their contents are, and so on.
Das war ein Grund weswegen ich von CherryPy auf Colubrid umgestiegen bin. Kann angehen
das ich es nur falsch versucht / gescriptet habe, aber wie ich es verstanden habe
ist es mit CherryPy verdammt einfach z.B. fremde Accounts per manipulierter URL
zu ändern / löschen / etc.

Normal kontrolliere ich ob die Daten per POST kommen und der Benutzer auch der ist, für
den er sich ausgibt. Aber da CherryPY POST / GET nicht wirklich unterscheidet machte
ich mir da mit CherryPy meine Sorgen das einer meinen Benutzern eine manipulierte URL unterschiebt.

Habe ich das nur falsch gemacht oder ist es ein "Problem" von CherryPy?
Ansonsten fand ich CherryPy richtig nett, aber nun bin ich mit Colubrid glücklich da ich eigentlich eh nicht mehr brauche als es bietet.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. Mai 2007, 10:43

fme hat geschrieben:aber wie ich es verstanden habe ist es mit CherryPy verdammt einfach z.B. fremde Accounts per manipulierter URL zu ändern / löschen / etc.
Also wenn es in deinem Programm vorkommt, dass wenn die Daten über das Falsche HTTP-Verb verschickt werden dass dann Accounts gelöscht werden, dann würde ich mir wirklich Sorgen machen. Denn in der Regel ist es kein Problem, die Zugriffsmethode zu wechseln, mit der Web Developer Extension ist das in Firefox kein Problem. Außerdem kann man Skripte mit der ``urllib`` schrieben, die entweder per GET oder per POST Daten schicken.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
fme
User
Beiträge: 34
Registriert: Sonntag 1. April 2007, 18:58
Wohnort: Bremen

Donnerstag 31. Mai 2007, 10:57

Zum löschen muss man schon das Passwort haben, aber einfache Daten am Account kann man auch so ändern.

Wenn jemand anderes die Formularmethode etc. ändert ist das nicht das Ding, weil er nicht eingeloggt
ist und so auch keinerlei Zugriff hat.
Das Problem ist vereinfacht gesagt, dass jemand eingelogt ist und jemand anderes in seinem Profiltext
einen manipulierten Link mit interessanten Text hinterlegt. Nun kommt ein "dummer" Benutzer angesurft
und klickt den Link an.
Schon könnten - theoretisch gesehen - Daten am eigenen Account geändert werden.
Andere Frameworks, die "unterscheiden" wo die Daten herkommen, verarbeiten das nicht. Aber da
CherryPy bei sowas nicht unterscheidet habe ich mir da schon Sorgen gemacht.
Aber kann auch angehen das ich nur paranoid bin und Sicherheitslücken sehe wo gar keine vorhanden sind.
Zuletzt geändert von fme am Donnerstag 31. Mai 2007, 11:00, insgesamt 1-mal geändert.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Donnerstag 31. Mai 2007, 11:00

fme hat geschrieben:Das war ein Grund weswegen ich von CherryPy auf Colubrid umgestiegen bin. Kann angehen
das ich es nur falsch versucht / gescriptet habe, aber wie ich es verstanden habe
ist es mit CherryPy verdammt einfach z.B. fremde Accounts per manipulierter URL
zu ändern / löschen / etc.
Unsicheren Code zu produzieren ist doch fast immer einfach ;)
fme hat geschrieben: Normal kontrolliere ich ob die Daten per POST kommen und der Benutzer auch der ist, für
den er sich ausgibt. Aber da CherryPY POST / GET nicht wirklich unterscheidet machte
ich mir da mit CherryPy meine Sorgen das einer meinen Benutzern eine manipulierte URL unterschiebt.
Wenn ich mich richtig daran erinnere habe ich das einfach mit einer einfachen if Klausel gelöst. Ein mit einem Decorator würde sich das ganze noch etwas schöner lösen lassen. Aber grundsätzlich gehört so etwas (meiner Meinung nach) in das URL Mapping.

Aber auch wenn du GET/POST unterscheidest besteht das Problem noch. Es ist jedoch schon etwas schwieriger Auszunützen (Der Benutzer muss eine HTML Seite aufrufen und nicht nur ein Bild o.ä.). Die von der Angesprochene Problematik nennt sich Cross Site Request Forgery. Eine wirklich elegante Lösung dazu habe ich noch nicht gesehen. Django bietet eine Middleware welche das Problem teilweise löst. Eine alternative ist das verwenden von HTTP Auth.

Interessant ist hier auch das sich diese Lücke in sehr vielen Seiten findet. Viele "Webentickler" (Progger *g*), sind sich dieser Problematik nicht Bewusst oder halten sie für Unwichtig/Minim weil nicht direkt Code ausgeführt werden kann.

Hier noch ein Link:
http://en.wikipedia.org/wiki/CSRF

fme hat geschrieben:Habe ich das nur falsch gemacht oder ist es ein "Problem" von CherryPy?
Ansonsten fand ich CherryPy richtig nett, aber nun bin ich mit Colubrid glücklich da ich eigentlich eh nicht mehr brauche als es bietet.
Das "Problem" von CherryPy ist das es dir dabei nicht hilft.

Ich habe mit CherryPy aber schon eine ganze Weile lang nicht mehr gespielt. Kann also gut sein das meine Aussagen nicht(mehr) Wahr sind ;)
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. Mai 2007, 11:06

fme hat geschrieben:Das Problem ist vereinfacht gesagt, dass jemand eingelogt ist und jemand anderes in seinem Profiltext
einen manipulierten Link mit interessanten Text hinterlegt. Nun kommt ein "dummer" Benutzer angesurft
und klickt den Link an.
Da hast du recht. Da hilft auch Referrer-Checken nicht. Wobei man sowas aber auch per GET absichern kann, schau dazu, wie phpBB es beispielsweise macht.
Natürlich - man sollte immer unterscheiden zwischen POST und GET. Das wird einem aber auch oft geraten, was auch sehr gut ist. Nur denkt man selten an CSRF.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 31. Mai 2007, 11:07

...gibt es auch in deutsch: http://de.wikipedia.org/wiki/Cross-Site_Request_Forgery

Zum Thema POST/GET ist der letzte Absatz interessant:
Wikipedia hat geschrieben:Nutzlose Maßnahmen

Der im Internet immer wieder anzutreffende Hinweis, eine Cross-Site Request Forgery sei dadurch zu verhindern, dass auf dem Server nur Requests per HTTP-POST als zulässig betrachtet werden, ist falsch. Auch per POST kann ohne weiteres ein gefälschter Request abgesetzt werden. Dazu erstellt der Angreifer eine Seite, auf das er das Opfer lockt. Dort wird der manipulierte Request entweder mittels einer clientseitigen Scriptsprache erzeugt oder der Angreifer bringt das Opfer dazu auf einen Button oder ein Bild zu klicken, wodurch der Request abgesetzt wird. Wählt der Angreifer als Ziel (target-Parameter) des Formulars einen unsichtbaren Frame oder Inlineframe, sind auch hier die Chancen gering, dass das Opfer den Angriff bemerkt.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. Mai 2007, 11:30

Richtig, deswegen muss man auch den Referer prüfen, ob der POST auch von "deiner" seite kommt und nicht von wo anders. Aber wenn wir das Beispiel von fme nehmen, dann kann dem User kein POST aus einem Link im Profil untergeschoben werden. Und wenn daten per POST kommen, muss man eben Referer prüfen.

Insgesamt ist CSRF ein komplexes Thema. Man müsste mal schauen, was die Django-Middleware da macht.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten