Benutzer-Werkzeuge

Webseiten-Werkzeuge


webserver:cgi
Alle Anleitungen in diesem Wiki beziehen sich auf Uberspace 6. Die Dokumentation für U7 findest du im neuen Manual. Im Lab findest du außerdem von Usern erstellte Anleitungen für verschiedene Projekte.

Uberspace 6 basiert auf CentOS 6, welches ab Ende 2020 keine Updates mehr bekommt. Wir raten dir, bis dahin auf Uberspace 7 umzuziehen. Eine Anleitung zum Umzug findest Du hier: uberspace2uberspace

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung
Vorherige Überarbeitung
webserver:cgi [2010/12/19 17:45]
uber angelegt
webserver:cgi [2015/11/29 07:41] (aktuell)
uber [Weitergehende Informationen]
Zeile 20: Zeile 20:
   AddHandler cgi-script .cgi   AddHandler cgi-script .cgi
  
-Anschließend werden alle Dateien mit der Endung ''.cgi'' als CGI-Script ausgeführt, auch außerhalb von ''cgi-bin''.+Anschließend werden alle Dateien mit der Endung ''.cgi'' als CGI-Script ausgeführt, auch außerhalb von ''cgi-bin''. Wichtig ist, dass die Scripts ausführbar sind - dazu solltest du die Rechte 0755 (Lese- und Ausführungsrechte für alle, Schreibrechte nur für dich) vergeben. Vergibst du weitergehende Schreibrechte, werden die Scripts aus Sicherheitsgründen nicht mehr ausgeführt; vergibst du weniger Rechte, kann der Webserver das Script möglicherweise nicht lesen und ausführen. Dies gilt nicht nur für das Script selbst, sondern auch für das Verzeichnis, in dem es liegt - setz also auch bitte für jenes mit einem ''chmod 755'' die entsprechenden Rechte. 
 + 
 +Wir auch bei der Ausführung via ''cgi-bin'' kommt auch hier suEXEC zum Tragen, das dafür sorgt, dass das Script nicht mit den Rechten des Webservers, sondern mit deinen Rechten gestartet wird. Es kann also genau die Dateien lesen und schreiben, die du auch auf der SSH-Shell lesen und schreiben kannst.
  
 Welchen Sinn hat dann noch ein separates ''cgi-bin''-Verzeichnis? Einer der Gründe ist, dass es damit schwerer wird, versehentlich den //Code// eines Scripts (der ja potentiell sensible Daten beinhalten kann oder aus anderen Gründen nicht öffentlich sein sollte) öffentlich zu machen. Viele Texteditoren wie ''vi'' oder ''nano'' legen beispielsweise Sicherungskopien von Dateien während der Arbeit an, oder bei einem erzwungenen Schließen des Editors (z. B. weil deine Internetverbindung abbricht, während du gerade mit dem Editor arbeitest). Der ''nano''-Editor beispielsweise würde beim Bearbeiten einer ''script.cgi''-Datei bei einem solchen Abbruch eine ''script.cgi.save'' hinterlassen. Liegt diese nun innerhalb des DocumentRoots und jemand ruft die URL ''.../script.cgi.save'' auf (einfach aufs Geratewohl!), so wird das Script nicht etwa ausgeführt, sondern //angezeigt// - der Server "erkennt" CGI-Scripts in diesem Fall ja nur an der Endung, und die lautet hier ''.save'' und nicht ''.cgi''. Der Aufrufende würde also deinen Programmcode einsehen können, was du möglicherweise nicht möchtest. Läge jene ''script.cgi.save'' jedoch im ''cgi-bin''-Verzeichnis, so würde sie beim Abruf dennoch ausgeführt, weil die Vorgabe von ''cgi-bin'' ist, dass //alles//, was darin liegt, als Script ausgeführt wird. Welchen Sinn hat dann noch ein separates ''cgi-bin''-Verzeichnis? Einer der Gründe ist, dass es damit schwerer wird, versehentlich den //Code// eines Scripts (der ja potentiell sensible Daten beinhalten kann oder aus anderen Gründen nicht öffentlich sein sollte) öffentlich zu machen. Viele Texteditoren wie ''vi'' oder ''nano'' legen beispielsweise Sicherungskopien von Dateien während der Arbeit an, oder bei einem erzwungenen Schließen des Editors (z. B. weil deine Internetverbindung abbricht, während du gerade mit dem Editor arbeitest). Der ''nano''-Editor beispielsweise würde beim Bearbeiten einer ''script.cgi''-Datei bei einem solchen Abbruch eine ''script.cgi.save'' hinterlassen. Liegt diese nun innerhalb des DocumentRoots und jemand ruft die URL ''.../script.cgi.save'' auf (einfach aufs Geratewohl!), so wird das Script nicht etwa ausgeführt, sondern //angezeigt// - der Server "erkennt" CGI-Scripts in diesem Fall ja nur an der Endung, und die lautet hier ''.save'' und nicht ''.cgi''. Der Aufrufende würde also deinen Programmcode einsehen können, was du möglicherweise nicht möchtest. Läge jene ''script.cgi.save'' jedoch im ''cgi-bin''-Verzeichnis, so würde sie beim Abruf dennoch ausgeführt, weil die Vorgabe von ''cgi-bin'' ist, dass //alles//, was darin liegt, als Script ausgeführt wird.
Zeile 26: Zeile 28:
 ===== Weitergehende Informationen ===== ===== Weitergehende Informationen =====
  
-Eine gute Einführung in CGI-Scripts findest du beispielsweise in der [[http://httpd.apache.org/docs/2.2/howto/cgi.html|Dokumentation des Apache-Webservers]]. Auch das Standardwerk [[http://de.selfhtml.org/|SELFHTML]] hat einen [[http://de.selfhtml.org/servercgi/cgi/index.htm|Abschnitt über CGI-Scripts]]. Beide können nur eine erste Anlaufstelle sein. Für tiefergehende Dokumentation solltest du in jedem Fall die CGI-spezifische Dokumentation der von dir gewählten Programmiersprache konsultieren.+Eine gute Einführung in CGI-Scripts findest du beispielsweise in der [[http://httpd.apache.org/docs/2.2/howto/cgi.html|Dokumentation des Apache-Webservers]]. Auch das Standardwerk [[http://de.selfhtml.org/|SELFHTML]] hat einen [[https://wiki.selfhtml.org/wiki/Doku:Perl/CGI|Abschnitt über CGI-Scripts]]. Beide können nur eine erste Anlaufstelle sein. Für tiefergehende Dokumentation solltest du in jedem Fall die CGI-spezifische Dokumentation der von dir gewählten Programmiersprache konsultieren.
webserver/cgi.1292777128.txt.gz · Zuletzt geändert: 2010/12/19 17:45 von uber