HTML-Dokument dynamisch erzeugt - leider ohne Bilder

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

Beitragvon numerix » Mittwoch 13. Februar 2008, 21:00

Hallo Gerold,

Letzter Versuch! Danach gebe ich es auf.


Nee, bloß nicht aufgeben! Allein deine Anstrengung, mir templates nahe zu bringen, ist schon beeindruckend. Ich bin (wenigstens im Moment) nur einfach die falsche Zielperson für deinen missionarischen Eifer: Ich habe vor zwei Tagen erstmals in meinem Leben einen Apachen installiert (naja, das war einfach) und konfiguriert (das ist nicht einfach), vor einigen Tagen erstmals mit CGI und SSI experimentiert und Python ist für mich ebenfalls Neuland. Das reicht mir für den Anfang.

Für alle, die es nicht interessiert:
Mein ursprüngliches Problem mit den fehlenden Bildern im HTML-Dokument habe ich jetzt lösen können. Dank Leonidas Hinweis habe ich der htaccess-Datei der AddHandler-Direktive jetzt eine Erweiterung verpasst und siehe da - der Server lässt die Ausführung von cgi-Skripten auch außerhalb von /cgi-bin zu. So kann ich jetzt in irgendeinem Unter-Unter-Ordner von /htdocs sowohl das cgi-Skript, als auch alle Bilder für das HTML-Dokument als auch die als Basis verwendete statische HTML-Datei unterbringen und mittels Skript das HTML-Dokument selbst auch wieder aufrufen. Bei den Bilddateien genügen jetzt einfach die Dateinamen oder vorangestellte Pfadangabe.

Frage an die Experten:
Ich habe einiges gelesen über die potentielle Gefahr von cgi-Skripten. Das habe ich auch soweit verstanden, glaube ich. Demnach ergeben sich für mich nun zwei grundsätzliche Möglichkeiten:

Variante 1
cgi-Skripte NUR im Verzeichnis /cgi-bin ablegen. Dann habe ich alle Skripte versammelt und kann sicher sein, dass nirgends sonst sich welche tummeln. Nachteil aus meiner Sicht: Der enge Zusammenhang zwischen einem Skript (das z.B. ein Formular ausliest) und der zugehörigen HTML-Datei geht dadurch verloren. Und mein Ausgangsproblem mit den Bilddateien lässt sich auf keine für mich angenehme Art lösen.

Variante 2
Ich erlaube die Ausführung von cgi-Skripten mittels .htaccess in allen (Unter-)Ordnern, wo ich es brauche. So kann ich die cgi-Skripte in den gleichen Ordner oder ggf. in einen Unterordner ../cgi o.ä. packen, wo die HTML-Datei(en) sind, mit denen das Skript zu tun hat.
Was mir nicht klar ist, ob (und inwiefern) das ein höheres Sicherheitsrisiko darstellt als Variante 1. Oder ob es sonstige Gründe gibt, dir mir bislang verborgen geblieben sind, dies so nicht zu tun.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 13. Februar 2008, 22:21

Mir ist eigentlich kein solches zusätzliches Risiko bekannt. Die Gründe hinter dem "CGIs nur in cgi-bin" sind vermutlich die, dass Provider nicht wollen das beliebige Skripte laufen, also werfen sie einige abgesegnete Skripte in den Ordner und geben dem Kunden dort keine Schreibrechte. Dieser Ansatz ist aber inzwischen wohl überholt - es ist nämlich so, dass PHP-Dateien überall ausgeführt werden. Also kein Grund sich den Kopf zu zerbrechen.

P.S.: Sowohl Jinja als auch Mako unterstützen Template-Vererbung. Zusätzlich noch Filter, die sich auch angenehm nutzen lassen ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Donnerstag 14. Februar 2008, 10:41

pütone hat geschrieben:Vielen Dank zunächst an euch drei Helfer für eure Tipps!
@keppla
Wie gerold dann anschließend angemerkt hat: Für den Anfang ist CGI unschlagbar. Und bei mir ist es der Anfang.


Das sehe ich anders.
das Ursprungsbeispiel in WSGI:

Code: Alles auswählen

def app(environ, start_response):
  file = open("../htdocs/pytest/cgitest.html","r")
  page = file.read()
  file.close()

  start_response(200, [('Content-Type', 'text/html')])
  return page


nicht komplizierter als cgi, aber mit dem vorteil, dass du es als cgi, mod_python, fcgi, standalone etc laufen lassen kannst, und middleware nutzen kasst.

Statische files? (middelware aus Werkzeug)

Code: Alles auswählen

app = SharedDataMiddleware(app, {
   '/publicpath' : '/path/im/dateisystem'
})


Du brauchst Sessions? (middelware aus flup)

Code: Alles auswählen

sessionStore = MemorySessionStore()
app = SessionMiddleware(sessionStore, app)


Dass CGI hinsichtlich Performance etc. die so ziemlich schlechteste Lösung ist, ist mir bewusst.

Ich meinte das nicht auf Performance bezogen, ich meinte das bezogen auf den Lerneffekt[/code]
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 14. Februar 2008, 12:50

keppla hat geschrieben:Du brauchst Sessions? (middelware aus flup)

Code: Alles auswählen

sessionStore = MemorySessionStore()
app = SessionMiddleware(sessionStore, app)

Die von flup ist deprecated. Da würde man inzwischen eher Beaker nutzen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Beitragvon Y0Gi » Donnerstag 14. Februar 2008, 13:27

pütone hat geschrieben:Variante 2
Ich erlaube die Ausführung von cgi-Skripten mittels .htaccess in allen (Unter-)Ordnern, wo ich es brauche. So kann ich die cgi-Skripte in den gleichen Ordner oder ggf. in einen Unterordner ../cgi o.ä. packen, wo die HTML-Datei(en) sind, mit denen das Skript zu tun hat.
Was mir nicht klar ist, ob (und inwiefern) das ein höheres Sicherheitsrisiko darstellt als Variante 1. Oder ob es sonstige Gründe gibt, dir mir bislang verborgen geblieben sind, dies so nicht zu tun.

Diese Variante habe ich lange auf Shared-Hosting-Webspace genutzt und für vergleichsweise angenehm befunden. Dank o.g. mod_rewrite ließen sich die - gerade für unbedarfte Anwender - unschönen Dateiendungen ausblenden und fertig war eine schöne Lösung auf CGI-Basis. Sicherheitsprobleme sehe ich da ebenfalls keine.


Leonidas hat geschrieben:Die von flup ist deprecated. Da würde man inzwischen eher Beaker nutzen.

Unlängst sogar. Oder aber neuerdings die von Werkzeug.

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]