Mit CherryPy .html Dateien liefern

[lunas]

Ich habe mal ein wenig mit cherryPy (3.0) herumgespielt und mir ist nach einigen Versuchen nur ein Weg eingefallen, wie ich z.B. die Seite http://localhost/foo.html durch cherryPy liefern kann. Es ist relativ einfach http://localhost/bar (ohne extension) abzurufen, aber wenn eine Dateinamenerweiterung im Namen enthalten ist, fällt mir nur ein Workaround ein. Die Frage ist nun: Ist das der normale (=richtige, durch die Entwickler vorgesehene) Weg oder tatsächlich nur ein Workaround? Ich frage nur, weil sich beide Methoden doch etwas unterscheiden und man (sprich: die Entwickler) im Allgemeinen schon auf ein wenig Orthogonalität bedacht ist...

Hier der Code (ein modifiziertes Tut-Beispiel):

Code: Alles auswählen

import cherrypy


class UsersPage:
    
    def index(self):
        return ""
    index.exposed = True

    def bar(self):
        return "auch okay"
    bar.exposed = True
    
    """ ist das der einzige Weg auf Dateinamen mit extension zuzugreifen?"""
    def default(self, site):        
        if site == 'foo.html'
            out = "test erfolgreich"
        else:
            out = "Unknown user. :-("        
        return '%s (<a href="./">back</a>)' % out
    default.exposed = True

cherrypy.tree.mount(UsersPage())

if __name__ == '__main__':
    import os.path
    cherrypy.config.update(os.path.join(os.path.dirname(__file__), 'tutorial.conf'))
    cherrypy.server.quickstart()
    cherrypy.engine.start()

Leider konnte ich für die Version 3.0 noch kein Manual finden (gibt's das schon irgendwo?), sodass ich hier erst einmal fragen muss...

lunas

[EnTeQuAk]

wozu möchtest du denn die *.html "Dateien" ausliefern?

Du könntest maximal via Apache + mod_rewrite die *.html Endung hinzudichten...


Etwas anderes ist mir noch nicht so ganz eingefallen...


MfG EnTeQuAk

[lunas]

Na angenommen ich habe in einer Seite einen link auf eine andere Seite. Klar könnte ich

Code: Alles auswählen

<a href="./foo">FOO</a>

schreiben, um die Seite zu verlinken, aber das ist doch schon ziemlich ungewöhnlich... Oder nicht? Wie findet denn cherryPy die Seite, wenn sie foo.html heißen würde?

[EnTeQuAk]

Über ungewöhnlich oder nicht lässt sich streiten
Ich finde es ansich "schöner", wenn nicht immer die ganzen Dateiendungen ind er URL stehen.

Nehm doch einfach mal an, du übergibst ein paar Daten via GET.

dann schaut die URL so aus:
www.dadada.xy/validation.html?valid=true?user=false


Fänd ich ehlich gesagt doof...


Es ginge noch die Möglichkeit, mit deinem kleinen Workaround oben eine "zentrale" "URL-Vermittlungsstelle" zu machen. dort werden die einzelnen URL's abgefragt und das Programm wird ensprechend "weitergeleitet".
Ich weiß aber nicht, ob das wirklich so vorteilhaft ist...


MfG EnTeQuAk

[gerold]

Ich habe mal ein wenig mit cherryPy (3.0) herumgespielt und mir ist nach einigen Versuchen nur ein Weg eingefallen, wie ich z.B. die Seite http://localhost/foo.html durch cherryPy liefern kann.

Hi lunas!

Vielleicht ist für dein Vorhaben Karrigell besser geeignet. Nach dem Entpacken der Tar-Datei, hast du (ohne weiteres Installieren) sofort einen lauffähigen Server zur Verfügung. Als Vorlagensprachen sind PSP und Cheetah (http://www.cheetahtemplate.org/) eingebaut. Karrigell liefert jede Datei direkt an den Browser aus, außer es gibt ein, für die Endung vorgesehenes, Handler-Modul.

Nach einer halben Stunde Testen von Karrigell weißt du, ob du damit zurecht kommst, oder ob du doch lieber eine andere Lösung vorziehst.

mfg
Gerold


PS: Ich habe gestern erfolgreich TAL als Vorlagensprache in Karrigell eingebaut. Allerdings bringt mir TAL ohne METAL noch nicht so viel, deshalb veröffentliche ich es erst, wenn auch METAL mit Acquisition (=so eine Art Vererbung) funktioniert.

[EnTeQuAk]

*sorry für leichtes offtopic*


Oh Oh da hat sich ja einer in Karigell verliebt

Karigell ist schon schön -- aber die Frage ist doch wohl auch. Möchtest du das später über einen Apachen betreiben?
Wenn ja läuft Karigell nur via mod_proxy, wenn ich das richtug bemerkt habe... Oder läuft das noch anders?


MfG EnTeQuAK

[lunas]

aber die Frage ist doch wohl auch. Möchtest du das später über einen Apachen betreiben?

Nö, will ich nicht. Soll ein standalone Progrämmchen werden.

@Gerold: Ich schau's mir mal an. Aber die Möglichkeit mit cherryPy jeden x-beliebigen Template-Parser einzusetzen hat mir erst mal ganz gut gefallen (habe Jinja gewählt). Eigentlich werden ja so ziemlich alle Seiten dynamisch generiert (sprich: es gäbe für jede Seite einen Handler), wenn ich nun die HTML Seiten ohne Endung speichern muss, dann wär' das ja auch nicht so schlimm - hat mich eben nur gewundert... Trotzdem, ich schau mir mal Deine Alternative an.

[gerold]

Möchtest du das später über einen Apachen betreiben? Wenn ja läuft Karigell nur via mod_proxy, wenn ich das richtug bemerkt habe...

Hi EnTeQuAK!

Zope läuft derzeit auch als eigenständiger Server und wird per mod_proxy durchgeschaltet und gecached. Das ist die Lösung, die ich seit Jahren schon hundertfach eingesetzt habe und diese Lösung funktioniert schnell und zuverlässig.

Karrigell ist so schnell gestartet, dass man es sogar über ein Skript vom Apachen starten lassen kann, falls es noch nicht gestartet ist. Das ist mit Zope nicht möglich. Karrigell ist eine reine Python-Lösung und kann überall mit eingebaut werden. Ich bin sogar schon beim Überlegen ob ich die Hilfeseiten für meine Programme nicht per Karrigell zur Verfügung stellen lassen soll. (z.B. für die Suche in den HTML-Hilfeseiten)

Alle Dateien mit der Endung .py werden mit Python ausgeführt. alle Dateien mit der Endung .tmpl werden an Cheetah weitergereicht. Und ich habe mir gestern einen Handler für die Endungen .tal und .talpy dazuprogrammiert. Das hat den Vorteil, dass wenn die TAL-Vorlage aufgerufen wird, geprüft wird, ob es eine zugehörige Datei mit der Endung .talpy gibt. Wenn Ja, dann werden die dynamischen Werte, die in der TAL-Vorlage gebraucht werden, von der talpy-Datei zur Verfügung gestellt. die talpy-Datei ist eine einfache Python-Datei, die die Werte an die Klasse ``THIS`` als Attribute anhängt.

Der für mich so große Vorteil ist der, dass ich wenn ich nicht will, keine große Anwendung sondern kleine Teilanwendungen habe. Eine Seite kann unabhängig von irgendeiner Hauptanwendung laufen. Im Hintergrund läuft aber ein Server, der sich um die Sessions und um die Zugriffsverwaltung kümmert.

Das ist die für mich einfachste Lösung, die trotzdem extrem flexibel bleibt. Ich pfeif auf dieses komplizierte WSGI, wo man für jeden kleinen Dreck eine eigene Funktion irgendwo einbauen muss. Karrigell läuft auf dem billigsten V-Host, braucht kaum Speicher und ist total einfach durchschaubar, installierbar und konfigurierbar. -- Ja, du hast recht. Es hat in mir einen Fan gefunden.

mfg
Gerold


PS: Genau so leicht, wie ich TAL einbauen konnte, dürften sich auch andere Vorlagensprachen wie KID oder Jinja einbauen lassen.

[EnTeQuAk]

Also so langsam überzeugst du mich, es mir auch mal anzuschauen


auf WSGI-Sch***** -- nun gut -- ich versuche meine Webanwendungen (wenn den mal) schon nach gewissen Standards zu richten.


Aber für den Privaten Gebrauch, wo ich selber bestimmen kann, mit welchem Untersatz ich arbeite... ist so etwas wunderbar.

Ganz nebenbei, fällt mir gerade ein habe ich ja auch den CherryPy-Server voa mod_proxy am laufen und lasse darüber meine Colubrid-Anwendungen laufen... Es ist schon einfach und Simpel... da hast du recht.


Eigentlich... um ehrlich zu sein... ich suche noch die Nachteile

Ich sitze ja hier grad @ Arbeit und kann nichts austesten (scheiß benutzer-rechte-einteilung... *grml*) -- wie programmiert sich denn Karigell?

Gibt es da ein paar schöne Beispiele, die man sehen kann? -- kannst du dazu etwas schreiben?

Würde mich freuen... heute mal wieder etwas hervorgehobenen Python-Code vor mir zu sehen...

MfG EnTeQuAk

[Leonidas]

Wo ist das Problem, CherryPy kann doch statische Daten liefern. Wir tippen in eine Suchmaschine Cherrpy static ein, klicken den ersten Link an. Nun sind wir auf einer Seite, die beschriebt, wie das mit CherryPy 2.2 zu bewerkstelligen ist. Also schauen wir in die Kommentare, wo als zweiter Kommentar die Anleitung für CherryPy 3 verlinkt ist.

[Y0Gi]

Die Endung .html zu verwenden, macht durchaus Sinn:
- Es wird (gegenüber anderen Dateiendungen) verschleiert, ob und wie die Dateien dynamisch generiert werden.
- Eine URL mit Dateiendung ist als Datei identifizierbar, während ohne Endung die Verwechselbarkeit zu Ordnern besteht, was manche Leute irritieren könnte.
- Die Leute sind teilweise .html gewohnt und daher weniger misstrauisch, bookmarken eher, etc.

[Leonidas]

- Es wird (gegenüber anderen Dateiendungen) verschleiert, ob und wie die Dateien dynamisch generiert werden.

So wie ich deine anderen Argumente durchaus nachvollziehen kann (wenn auch nicht umbedingt zustimme, wenn man sich schon allein die Google- oder Amazon-URLs ansieht wird der User überhaupt entmutigt, sich die URL anzusehen weil sie zwei bis dreimal länger ist als die Adressleiste, T-Com macht es eben genau so) so sehe ich nicht ganz den Zweck darin, zu verschleiern, ob eine Seite dynamisch oder statisch ist.

[lunas]

Wo ist das Problem, CherryPy kann doch statische Daten liefern. Wir tippen ...

Darum ging's ja nicht (oder worauf bezog sich der Post?). Ich wollte lediglich die generierten html Dateien (-Templates) mit der Endung .html abspeichern. Sie sind also nicht statisch, sondern dynamisch...

Ich scheine noch eine halbwegs brauchbare Lösung gefunden zu haben:

Code: Alles auswählen

...
""" dir mit sämtlichen dynamisch generierten Dateien """
t['foo.html'] = Template('foo', FileSystemLoader('./html'))
...
def default( self, tag ):
        return t[tag].render(c)
    default.exposed = True

Die statischen Dateien kann ich dann, mit Hilfe Leonidas Hinweis, am Template Prozessor vorbeischleusen (insofern war der Tipp schon brauchbar).

Habt recht vielen Dank für die Hinweise.

@Gerold: Karrigell scheint mir für meine Mini-Anwendung overkill zu sein. Z.B. brauche ich keine Datenbankanbindung. Trotzdem, gut mal davon gehört zu haben. Vielleicht ergibt sich zukünftig mal ein Anwendungsfall dafür...

[Y0Gi]

so sehe ich nicht ganz den Zweck darin, zu verschleiern, ob eine Seite dynamisch oder statisch ist.

Dazu siehe

- Die Leute sind teilweise .html gewohnt und daher weniger misstrauisch, bookmarken eher, etc.

Mir ging es aber nicht darum, die reine Dynamik zu verschleiern, sondern die dahinter stehende Software. "Auf .php stürzt sich jedes Script-Kiddie." Die Dateiendung verrät oft sofort, welche Software eingesetzt wird und zieht insbesondere bei frischen Exploits Aufmerksamkeit auf sich - sei es genaueres "Hinsehen" bei zufälligem Besuch oder automatisierte Suche nach bestimmten Dateiendungen.

[Leonidas]

Mir ging es aber nicht darum, die reine Dynamik zu verschleiern, sondern die dahinter stehende Software. "Auf .php stürzt sich jedes Script-Kiddie." Die Dateiendung verrät oft sofort, welche Software eingesetzt wird und zieht insbesondere bei frischen Exploits Aufmerksamkeit auf sich - sei es genaueres "Hinsehen" bei zufälligem Besuch oder automatisierte Suche nach bestimmten Dateiendungen.

In den neueren Python-Framworks die ich mir genauer angesehen habe ist, lassen die URLs nicht darauf schließen, welche Software verwendet wird. Im Falle Djangos hören die zwar fast immer mit einem Slash auf (und werden, wenn sie das nicht tun automatisch auf eine Seite mit abschließendem Slash weitergeleitet), aber auch das lässt sich abschalten.

Ist also im Fall von PHP oder ASP(.NET) noch eine Idee, aber für CherryPy eher unsinnig. Besser die Zeit investieren und mit AppArmor oder SELinux den CherryPy-Prozess absichern.

[Y0Gi]

Das war auch weder auf CherryPy oder Frameworks speziell bezogen