Authentifizierung mit CGI/Perl

[Nico]

Hallo,

kann ich den Zugriff auf cgi-Skripten steuern?

Ich habe gehört, man könnte in das Verzeichnis mit den Skripten eine .htaccess-Datei legen, dies wäre aber nicht zu emfehlen. Ich möchte aber, daß die Ausgabe meiner Skripten nur authentifizierten Usern gezeigt wird.

Gruß
Nico

[AlexBausW]

Hallo,

kann ich den Zugriff auf cgi-Skripten steuern?

Ich habe gehört, man könnte in das Verzeichnis mit den Skripten eine .htaccess-Datei legen, dies wäre aber nicht zu emfehlen. Ich möchte aber, daß die Ausgabe meiner Skripten nur authentifizierten Usern gezeigt wird.

Die Methode per .htaccess eine Authentikation zu realisieren, ist imho die empfehlenswerteste, da es erstens prima funktioniert und zweitens man im Skript keine unbedachten Fehler einbauen kann, wenn man denn mit Passwort und Sessions arbeiten will.
Wenn Du dann im Skript zusätzlich $ENV{'REMOTE_USER'} auf einen zulässigen Wert überprüfst, kann eigentlich nicht viel schief gehen (außer, daß der Server anfängt alle Dateien asis auszuliefern ;)

Gruß Alex

[Michael Schröpl]

Hi Nico,

kann ich den Zugriff auf cgi-Skripten steuern?

ja. Bezüglich Zugriffskontrolle ist dem Webserver zunächst einmal egal, ob die angeforderte Ressource ein CGI-Skript ist oder irgend etwas anderes.

Ich habe gehört, man könnte in das Verzeichnis mit den Skripten eine .htaccess-Datei legen, dies wäre aber nicht zu emfehlen.

Zumindest sprechen keine technischen Gründe dagegen. Meine Anmerkung in http://aktuell.de.selfhtml.org/artikel/server/htaccess-faq/#a2 ist jedenfalls völlig veraltet und bezog sich anscheinend nur auf eine einzige, fehlerhafte Apache-Version aus dem Jahr 1999.

Ich möchte aber, daß die Ausgabe meiner Skripten nur authentifizierten Usern gezeigt wird.

Aller Skripte? Oder nur einiger?

Wahrscheinlich ist es wartungsfreundlicher für die Zukunft, gleich ein Unterverzeichnis /cgi-bin/secure oder so ähnlich anzulegen und nur dieses via Server Authentication zu schützen.
(das _kann_ via .htaccess erfolgen, aber auch in der zentralen Konfiguration selbst, falls Du darauf schreibenden Zugriff haben solltest.)

Viele Grüße
      Michael

[i-netlab]

Moin,

kann ich den Zugriff auf cgi-Skripten steuern?

Ich habe gehört, man könnte in das Verzeichnis mit den Skripten eine .htaccess-Datei legen, dies wäre aber nicht zu emfehlen. Ich möchte aber, daß die Ausgabe meiner Skripten nur authentifizierten Usern gezeigt wird.

Mit einer .htaccess im Scriptverzeichnis kann ein Benutzer ein Script nur aufrufen wenn er sich authentifiziert anhand der in der .htaccess definierten Passwortdatei. Das heißt, vorher bekommt er das Script gar nicht erst zu sehen. Das heißt auch dass du eine eigene Benutzerverwaltung auf dem Server haben musst, nämlich die Passwortdatei.

http://i-netlab.de/article/htpasswd.html

Bei einem größeren Benutzerkreis ist sowas nicht mehr machbar, insbesondere wenn es für diese Benutzer mehrere *Realms* geben soll... entstehen leicht Inkonsistenzen und die Übersicht ist nicht mehr gegeben. Da gibt es auch noch andere Möglichkeiten wie z.B. eine Authentifikation über einen LDAP Server wo die Benutzer zentral verwaltet werden. Mit dem PERL Modul Net::LDAP resp. LDAPS kannst du auch solch ein Problem lösen:  Der User kann das CGI (~Formular) aufrufen, aber erst submitten wenn er sich authentifiziert hat. Bitte denke daran, dass Benutzereingaben immer vertraulich zu behandeln sind, auch innerhalb einer Firma (gerade dort) und eine Sichere Verbindung (https, LDAPS) dringend empfohlen ist, sonst gehen auch die Passwords im Klartext übers Netz.

Rolf

[Michael Schröpl]

Hi i-netlab,

Bei einem größeren Benutzerkreis ist sowas nicht mehr machbar, insbesondere wenn es für diese Benutzer mehrere *Realms* geben soll... entstehen leicht Inkonsistenzen und die Übersicht ist nicht mehr gegeben.

was hindert Dich daran, für die diversen Realms entsprechende Benutzergruppen zu bilden?

Viele Grüße
      Michael

[i-netlab]

hi Michael,

Bei einem größeren Benutzerkreis ist sowas nicht mehr machbar, insbesondere wenn es für diese Benutzer mehrere *Realms* geben soll... entstehen leicht Inkonsistenzen und die Übersicht ist nicht mehr gegeben.

was hindert Dich daran, für die diversen Realms entsprechende Benutzergruppen zu bilden?

Stell dir mal Folgendes vor:

2.000 Benutzer
5 Realms

Von den 2.000 Benutzern sollen die Benutzer 1 - 9 Zugriff auf Realm 1 und 2 haben, die Benutzer 10 und Benutzer 11 haben Zugrif auf Realm 3 und 4, Benutzer 11 zusätzlich auf Realm 5. Benutzer 12 darf auf Realm 1 und 2, Benutzer 13 darf Realm 2, 3 und 4 und so geht das weiter bis zum Benutzer 2.000

Irgendwann verläßt Benutzer 43 die Firma, es kommt ein Neuer...

Falls du sowas mal mit .htaccess gelöst hast lächele einfach ;-)

Rolf

[Michael Schröpl]

Hi i-netlab,

Von den 2.000 Benutzern sollen die Benutzer 1 - 9 Zugriff auf Realm 1 und 2 haben, die Benutzer 10 und Benutzer 11 haben Zugrif auf Realm 3 und 4, Benutzer 11 zusätzlich auf Realm 5. Benutzer 12 darf auf Realm 1 und 2, Benutzer 13 darf Realm 2, 3 und 4 und so geht das weiter bis zum Benutzer 2.000

Das ist schon die falsche Denkweise, finde ich.

Definiere nicht aus der Sicht der Benutzer, auf welche Realms sie zugreifen dürfen - definiere es aus der Sicht der Realms.
Klassifiziere also Deine Benutzer in Gruppen (z. B. nach Büro-Abteilungen, nach Sicherheitsstufen etc.), und dann gewähre bestimmten Gruppen (!) den Zugriff auf bestimmte Realms.

Irgendwann verläßt Benutzer 43 die Firma, es kommt ein Neuer...
Falls du sowas mal mit .htaccess gelöst hast lächele einfach ;-)

Überhaupt kein Problem: Du entfernst den Benutzer 43 aus seiner Gruppe (bzw. seinen Gruppen) und trägst jeden neuen Benutzer in die erforderlichen Gruppen ein.
An der Definition der Realms ändert sich bei _keiner_ dieser beiden Operationen _irgendwas_ - Du hast über die Gruppen eine Abstraktionsebene dazwischen geschaltet.

Den Zugriff auf eine Realm auf Personenbasis zu definieren, das wäre bein Deiner Menge von Benutzern in der Tat ein Alptraum. Also: Mach's einfach richtig[tm]. ;-)

Viele Grüße
      Michael

[i-netlab]

Hallo Michael,

Von den 2.000 Benutzern sollen die Benutzer 1 - 9 Zugriff auf Realm 1 und 2 haben, die Benutzer 10 und Benutzer 11 haben Zugrif auf Realm 3 und 4, Benutzer 11 zusätzlich auf Realm 5. Benutzer 12 darf auf Realm 1 und 2, Benutzer 13 darf Realm 2, 3 und 4 und so geht das weiter bis zum Benutzer 2.000

Das ist schon die falsche Denkweise, finde ich.

Bei vielen Benutzern und verschiedenen Realms (die sich überdies auch noch auf verschiedenen Systemen befinden) ist die LDAP Strategie richtig, denn die heißt:

Zentrale Benutzerverwaltung.

Der Programmierer einer Webanwendung braucht sich somit um die Verwaltung der User nicht zu kümmern, das ist auch gar nicht dem seine Aufgabe.

Schönes Wochenende, Rolf