WebServer - Projekt 3

Ganz analog soll für den Verein nun eine Seite eingerichtet werden, auf der man Termine ankündigen kann. Wir wollen aber nun mit unterschiedlich vertrauensvollen CGI-Methoden arbeiten.

Ganz analog zu VereinsDaten.pl erstellen wir das Perl-Script Termine.pl. Wegen der mehrzeiligen Eingaben müssen wir nun mit der Datenhaltung aufpassen - wir makieren die Zeilenumbrüche mit den Funktionen escape bzw. demaskieren mit unescape. (Als Übung: Was ist an dem Verfahren falsch?)

Die unterschiedlichen Wege zum CGI sind in den 3 neu-Varianten verborgen:

1. Neuer Eintrag (1) bzw. neu.html arbeitet wie gehabt: Wir verwenden als Script die Datei in /share/www/apache/cgi-bin/VereinsTermine-1.3, die mir gehört. Die könnte natürlich auch dem Webmaster gehören, der dann für jede Änderung befragt werden müsste.
2. Nicht ausgeführt habe ich die Varinate, das /share/www/apache/cgi-bin/VereinsTermine-1.3 ein symbolischer Link auf eine Datrei irgendwo in meinem Homebereich ist. Das kann via der Option FollowSymLinks erlaubt bzw. verboten werden.
3. Neuer Eintrag (2) bzw. neu-lammers.html arbeitet auch mit symlinks aus /share/www/apache/cgi-bin, allerdings habe ich hier gleich ein ganzes Verzeichnis gelinkt. Sinnvoll, wenn der Scriptautor vertrauesnwürdig ist, denn er kann dan beliebige Scripten eintragen, ohne den Webmaster involvieren zu müssen.
4. Neuer Eintrag (3) bzw. neu-lammers2.html verwendet als ScriptAlias /u/lammers/htbin - ist das einmal mit den Direktiven ScriptAlias und der Option ExecCGI eingetragen, ist der Effekt der gleiche wie im vorhergehenden Fall - diese Lösung würde aber auch unter Betriebssystemen gehen, die keine Symlinks erlauben, da die Auflösung der Referenz duch apache erfolgt.

   <Directory /u/lammers/WWW/cgi-bin>
   AllowOverride None
   Options +ExecCGI
   </Directory>
   
   ScriptAlias /u/lammers/htbin /u/lammers/WWW/cgi-bin
   	    

5. Eine Variante, die hier auch nicht realisert wurde, ist, die Angabe von ScriptAlias und ExecCGI in .htaccess-Dateien freizugeben. Das eröffnet dann jedem Webseitenanbieter, Scripten anch seiner Wahl ohne jedwede Rücksprache mit dem Webmaster zu installieren. Sollte man wohl eher nicht erlauben.

Weil es hier gerade auch um Sicherheit ging: Man sollte den Zugriff auf geschützte Bereichen i.A. über ssl-codierte Verbindungen mit einem https-Server realisieren. Demo3-secure ist ein Beispiel dafür.