[Thread Prev][Thread Next]   >Date Index >Thread Index

Re: CGI Session (Login) Example?

Harald Joerg - Tue Jul 24 22:43:15 2007

Wilfried Gaensheimer fragt in die Runde: <wilfried@gaensheimer.de> writes:

> ich suche eine Anleitung bzw. ein Beispiel, wie man ein Perl CGI-Skript
> mit einer Login-Funktionalitaet ausstattet. Es sollte aber auch
> ohne Login funktionieren (und damit scheidet ein primitives
> "require valid-user" wohl aus).

Wie passend.  Ich halte am Donnerstag in unserer Firma einen Vortrag
über Authentisierung in den verschiedenen "Protokollebenen" beim Web :-)

> Also wie in einem online-Shop, wo man
> sich per "Login" zu einer beliebigen Zeit einfach anmelden kann.
>
> Kurz gesprochen geht es um ein CGI-Skript, das fuer nicht angemeldete
> User nur was zum Ansehen ausgibt, sobald man sich anmeldet werden (je nach
> den diesem Login zugeordneten Moeglichkeiten) weitere Funktionen
> eingeblendet.
>
> Ich habe jetzt schon eine Zeit sourceforge und google bemueht, bin
> aber noch nicht so ganz gluecklich.
>
> Bei sourceforge habe ich z.B. "UserLogin" gefunden, aber da wird
> IMHO Mason vorausgesetzt (http://sourceforge.net/projects/userlogin/)
> und es scheint schon recht alt zu sein (2001).
>
> Auch bei CPAN wurde ich nicht fuendig. Wahrscheinlich bin ich nur
> einfach blind? Z.B. CGI::Session ist schon nahe dran.
> CGI::Auth noch dazu ....

Wie meistens, gibt es mehrere Möglichkeiten.  Die zwei naheliegendsten:

1) Login per HTML-Formular

2) Login per Webserver-Konfiguration und HTTP-Headern

1) wird zum Beispiel bei CGI::Auth praktiziert, wobei ich die
   Implementierung als URL-Parameters für eher klapprig halte.
   CGI::Session mit CGI::Cookie ist da doch etwas solider. Die
   Benutzerkennung steht in dem Fall normalerweise in einem Tempfile am
   Server, das über den Cookie-Inhalt identifiziert wird.
   Benutzerkennungen und Passwörter verwaltest Du wie Du willst in
   Deiner Anwendung.

2) ist gar nicht sooo unmöglich, auch in Deinem Fall nicht.  Das
   "normale" Angucken der Seiten machst Du mit HTTP, und die Login-Seite
   ist eine HTTPS-URL - nach dem Login bedienst Du die gleichen Seiten
   wie zuvor, nur dass eben die HTTPS-Url mit "require valid-user"
   bedient ist.  Die Benutzerkennung bekommst Du bei "normalen" CGIs als
   $ENV{REMOTE_USER}.  Verwaltung der Benutzerkennungen und Passwörter
   macht dann der Webserver, bei Apache mit einer reichen Auswahl an
   Backends, zu dem Du, wenn Du lustig bist, Schnittstellen via CGI
   anbieten kannst.  Alternativ zu HTTPS kannst Du auch einfach einen
   anderen Port für die Login-Sessions verwenden.

Womit wir schon zu den Haken und Ösen kämen: Bei 1) gibt es immer noch
Leute, die keine Cookies mögen.  Weil aber HTTP ein zustandsloses
Protokoll ist, brauchst Du irgendwas, um den Zustand "eingeloggt"
mitzuführen.  Bei 2) gibt's keinen "Logoff" - nicht, weil es das
Protokoll nicht hergibt, sondern weil die Browser es nicht implementiert
haben.  Und in beiden Fällen musst Du überlegen, ob Du die Passwörter im
Klartext über die Leitung gejagt haben möchtest: Bei 1) gibt's
eigentlich nur HTTPS als echte Alternative, bei 2) dazu noch mod_digest.

Es kommt jetzt nur noch drauf an, wie viel Code Du durchlesen möchtest.
TWiki kann beispielsweise beides, als "TemplateLogin" die Variante 1)
und als "ApacheLogin" die Variante 2).  Der Code ist aber einigermaßen
verschwurbelt, weil's so viele Konfigurationsparameter gibt.

Die Variante 2) ist recht einfach, weil man dazu keinen Code braucht.

Falls Du ein noch einfacheres Beispiel im Internet findest: Wirf's weg.
Das taugt nix.

Zwei weitere nicht so naheliegenden Möglichkeiten sind ein Login per
Java-Applet, wo die Anwendung aber machen kann was sie will, weil HTTP
"nur noch" das Transportprotokoll ist, und Login per
Client-SSL-Zertifikat.
-- 
Good luck,
haj


Next: