nicht angemeldet
Authorization Header
Hallo allerseits,
Indem man diese Header ausgibt, kann man den Client auffordern sich mit Benutzername und Passwort zu identifizieren.
status: 401
www_authenticate: basic realm="bla"
Der Client versieht die Anfrage dann mit einem Authorization: ... Header.
Wie kann man mit einem CGI-Programm nun an diesen Header kommen?
Grüße
Daniel
-
Hi Daniel Thoma,
lass Dir doch mal die CGI-Umgebungsvariablen ausgeben. In Perl:
my $var_name;
foreach $var_name (sort keys %ENV) {
print "<P><B>$var_name</B><BR>";
print $ENV{$var_name};
}Variablen wie AUTH_TYPE, die die Authentifizierungsmethode angibt, oder REMOTE_USER, die den authentifizierten Namen des Users angibt, sind natürlich nur definiert, wenn auch eine Authentifizierung gefordert war.
Viele Grüße
Mathias Bigge-
Hallo,
my $var_name;
foreach $var_name (sort keys %ENV) {
print "<P><B>$var_name</B><BR>";
print $ENV{$var_name};
}Das habe ich natürlich schon gemacht.
Variablen wie AUTH_TYPE, die die Authentifizierungsmethode angibt, oder REMOTE_USER, die den authentifizierten Namen des Users angibt, sind natürlich nur definiert, wenn auch eine Authentifizierung gefordert war.
Das genau ist das Problem. Da übernimmt der Server die Authentifizierung, ich will das aber im Script erledigen.
Sieht so aus, als ob ich auf einen Authentifizierungsmechanismus mit Cookies o.ä. ausweichen muss.Grüße
Daniel
-
Halihallo Daniel
Variablen wie AUTH_TYPE, die die Authentifizierungsmethode angibt, oder REMOTE_USER, die den authentifizierten Namen des Users angibt, sind natürlich nur definiert, wenn auch eine Authentifizierung gefordert war.
Das genau ist das Problem. Da übernimmt der Server die Authentifizierung, ich will das aber im Script erledigen.
Sieht so aus, als ob ich auf einen Authentifizierungsmechanismus mit Cookies o.ä. ausweichen muss.Wieso? - Du schickst den HTTP-Header "Authentication Required", falls kein $ENV{AUTH_TYPE} gesetzt ist, dann kommt im Browser der Dialog. Gibt der User seine Logininfos ein, kommt ein neuer Request auf das Script, diesesmal jedoch die %ENV zur Authentication gesetzt, diese kannst du dann auslesen ($ENV{REMOTE_USER}, ...) und verifizieren, ob der Login richtig ist. Ein "Autentication Failed" - Header falls nicht, die gewünschte Seite falls richtig. Die Authentication-Informationen sind in der aktuellen Browser-Session gültig, du musst sie jedoch mit jedem Zugriff neu überprüfen.
Viele Grüsse
Philipp
-
Halihallo
Wieso? - Du schickst den HTTP-Header "Authentication Required", falls kein $ENV{AUTH_TYPE} gesetzt ist, dann kommt im Browser der Dialog. Gibt der User seine Logininfos ein, kommt ein neuer Request auf das Script, diesesmal jedoch die %ENV zur Authentication gesetzt, diese kannst du dann auslesen ($ENV{REMOTE_USER}, ...) und verifizieren, ob der Login richtig ist. Ein "Autentication Failed" - Header falls nicht, die gewünschte Seite falls richtig. Die Authentication-Informationen sind in der aktuellen Browser-Session gültig, du musst sie jedoch mit jedem Zugriff neu überprüfen.
Ich glaube, das war eine Fehlinformation von mir. REMOTE_USER wird IMHO nicht durch den Apachen übergeben, ausser man programmiert mod_perl oder mod_auth um??? - Sorry. Zumindest habe ich diesbezüglich nix im web gefunden.
Viele Grüsse
Philipp
-
Halihallo
Wieso? - Du schickst den HTTP-Header "Authentication Required", falls kein $ENV{AUTH_TYPE} gesetzt ist, dann kommt im Browser der Dialog. Gibt der User seine Logininfos ein, kommt ein neuer Request auf das Script, diesesmal jedoch die %ENV zur Authentication gesetzt, diese kannst du dann auslesen ($ENV{REMOTE_USER}, ...) und verifizieren, ob der Login richtig ist. Ein "Autentication Failed" - Header falls nicht, die gewünschte Seite falls richtig. Die Authentication-Informationen sind in der aktuellen Browser-Session gültig, du musst sie jedoch mit jedem Zugriff neu überprüfen.
Ich glaube, das war eine Fehlinformation von mir. REMOTE_USER wird IMHO nicht durch den Apachen übergeben, ausser man programmiert mod_perl oder mod_auth um??? - Sorry. Zumindest habe ich diesbezüglich nix im web gefunden.
REMOTE_PASS meinte ich. Warum wird dies eigentlich nicht übertragen? - Wäre IMO sinnvoll, natürlich auch eine potenzielle Sicherheitslücke. Wie geht dann (oder überhaupt?) eine Authentication _nur_ über CGI (nicht über .htaccess)?
Viele Grüsse
Philipp
-
Moin!
REMOTE_PASS meinte ich. Warum wird dies eigentlich nicht übertragen? - Wäre IMO sinnvoll, natürlich auch eine potenzielle Sicherheitslücke. Wie geht dann (oder überhaupt?) eine Authentication _nur_ über CGI (nicht über .htaccess)?
Wenn der Apache beispielsweise auf die Passwortdaten zugreift, die das CGI-Skript irgendwo abgespeichert hat, kann man .htaccess-Methoden benutzen. Möglich sind dabei u.a. die berühmte .htpasswd-Datei (die man per Skript generieren lassen kann), oder auch eine MySQL-Datenbank (was bei hohen Userzahlen performanter ist).
Die Angabe "REMOTE_USER" ist jedenfalls schon authentifiziert.
CGI-Skripte können natürlich auch den gesamten HTTP-Verkehr kriegen. Dann sind sie für's Parsen und verstehen der empfangenen Daten aber auch selbst verantwortlich. Ein gutes Beispiel dafür wäre z.B. Michael Schröpls "http_trace.pl". Das kommt (ich müßte nachgucken, wie genau - sicherlich gibts dazu ein Modul) irgendwie an den vom Browser gesendeten Header heran und gibt ihn weiter an den zu befragenden Server.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hallo,
CGI-Skripte können natürlich auch den gesamten HTTP-Verkehr kriegen. Dann sind sie für's Parsen und verstehen der empfangenen Daten aber auch selbst verantwortlich. Ein gutes Beispiel dafür wäre z.B. Michael Schröpls "http_trace.pl". Das kommt (ich müßte nachgucken, wie genau - sicherlich gibts dazu ein Modul) irgendwie an den vom Browser gesendeten Header heran und gibt ihn weiter an den zu befragenden Server.
Das klingt gut, wo gibt es dieses Script?
Grüße
Daniel
-
use Mosche;
CGI-Skripte können natürlich auch den gesamten HTTP-Verkehr kriegen. Dann sind sie für's Parsen und verstehen der empfangenen Daten aber auch selbst verantwortlich. Ein gutes Beispiel dafür wäre z.B. Michael Schröpls "http_trace.pl". Das kommt (ich müßte nachgucken, wie genau - sicherlich gibts dazu ein Modul) irgendwie an den vom Browser gesendeten Header heran und gibt ihn weiter an den zu befragenden Server.
Das klingt gut, wo gibt es dieses Script?Zu finden ist es unter http://www.schroepl.net/cgi-bin/http_trace.pl.
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.-
Hallo,
Danke, aber das habe ich mittlerweile selbst gefunden.
Mich hätte vielmehr der Quellcode interessiert.Grüße
Daniel
-
Hallo,
Ich habe das Script gerade mal ausprobiert und festgestellt, dass es die Authentifizierungsdaten auch nicht ausgibt.
Scheint einfach eine schwäche der CGI-Schnittstelle zu sein. Es ist mir ein Rätsel, warum diese Daten nicht übertragen werden.Grüße
Daniel
-
Hi Daniel,
die Sicherheitsprobleme dürften riesig sein, wenn die Passwörter unverschlüsselt über die CGI-Umgebung zugänglich wären. Ich will das nicht im einzelnen ausmalen, es gehört ja nicht viel Phantasie dazu.
Du hast doch einen autorisierten Benutzernamen, erklär doch mal, warum Dir das nicht ausreicht, alles zu steuern, was Du steuern willst, das habe ich bisher noch nicht verstanden.
Viele Grüße
Mathias Bigge-
use Mosche;
die Sicherheitsprobleme dürften riesig sein, wenn die Passwörter unverschlüsselt über die CGI-Umgebung zugänglich wären. Ich will das nicht im einzelnen ausmalen, es gehört ja nicht viel Phantasie dazu.
Du hast doch einen autorisierten Benutzernamen, erklär doch mal, warum Dir das nicht ausreicht, alles zu steuern, was Du steuern willst, das habe ich bisher noch nicht verstanden.
Er will den Handler schreiben, der die Sicherheitsüberprüfung vornimmt. Das geht meines Wissens ohne Serverkonfigurationsdirektiven (Umgangsdeutsch: ".htaccess") nicht.
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell. -
Hallo Mathias,
die Sicherheitsprobleme dürften riesig sein, wenn die Passwörter unverschlüsselt über die CGI-Umgebung zugänglich wären. Ich will das nicht im einzelnen ausmalen, es gehört ja nicht viel Phantasie dazu.
Was soll daran so problematisch sein, wenn ein CGI-Script die Zugangsdaten übermittelt bekommt, die der Browser schickt?
Du hast doch einen autorisierten Benutzernamen, erklär doch mal, warum Dir das nicht ausreicht, alles zu steuern, was Du steuern willst, das habe ich bisher noch nicht verstanden.
Ich habe die Benutzerdaten in einer Datenbank stehen, kann aber leider nur Textdateien zur Benutzerauthentifizierung mit dem Apache verwenden.
Grüße
Daniel
-
use Mosche;
Ich habe die Benutzerdaten in einer Datenbank stehen, kann aber leider nur Textdateien zur Benutzerauthentifizierung mit dem Apache verwenden.
Es gibt mehrere Module, die man da benutzen kann (mod_auth_(pg|mysql)). Du kannst auch ein CGI-Script schreiben, welches die Authentifizierung übernimmt - nur nicht _ohne_ .htaccess. Du musst Konfigurationsdirektiven irgendeiner Art setzen - also .htaccess oder httpd.conf.
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.-
Hallo,
Es gibt mehrere Module, die man da benutzen kann (mod_auth_(pg|mysql)).
Das ist mir klar. Allerdings kann ich diese Module leider nicht einsetzen.
»»Du kannst auch ein CGI-Script schreiben, welches die Authentifizierung übernimmt - nur nicht _ohne_ .htaccess. Du musst Konfigurationsdirektiven irgendeiner Art setzen - also .htaccess oder httpd.conf.
Nur weil ich irgend was in eine .htaccess-Datei schreibe, schickt mir der Server plötzlich die Authentifizierungsdaten mit oder wie meinst Du das?Grüße
Daniel
-
-
-
-
-
-
-
-
Halihallo Sven
REMOTE_PASS meinte ich. Warum wird dies eigentlich nicht übertragen? - Wäre IMO sinnvoll, natürlich auch eine potenzielle Sicherheitslücke. Wie geht dann (oder überhaupt?) eine Authentication _nur_ über CGI (nicht über .htaccess)?
Wenn der Apache beispielsweise auf die Passwortdaten zugreift, die das CGI-Skript irgendwo abgespeichert hat, kann man .htaccess-Methoden benutzen. Möglich sind dabei u.a. die berühmte .htpasswd-Datei (die man per Skript generieren lassen kann), oder auch eine MySQL-Datenbank (was bei hohen Userzahlen performanter ist).
Ist mir bewusst. Schöner wäre es jedoch gewesen, wenn man ohne .htpasswd und .htaccess auskommen könnte und die Authentifizierung _allein_ über CGI realisieren könnte. Ein Perlscript, welches REMOTE_USER und REMOTE_PASS einliest, mit Daten woher auch immer vergleicht und dann Entscheidungen trifft (Status 200/401).
Die Angabe "REMOTE_USER" ist jedenfalls schon authentifiziert.
Ja, schön wäre, wenn auch auf REMOTE_PASS zugegriffen werden könnte.
CGI-Skripte können natürlich auch den gesamten HTTP-Verkehr kriegen. Dann sind sie für's Parsen und verstehen der empfangenen Daten aber auch selbst verantwortlich. Ein gutes Beispiel dafür wäre z.B. Michael Schröpls "http_trace.pl". Das kommt (ich müßte nachgucken, wie genau - sicherlich gibts dazu ein Modul) irgendwie an den vom Browser gesendeten Header heran und gibt ihn weiter an den zu befragenden Server.
Das wäre, wie Daniel schon sagt, die Lösung. Nur müsste man IMO einen Webserver emulieren (sprich listen auf dem 80 Port...), was keine sehr gute Lösung ist (zwei Programme auf dem selben Port...). Ich wüsste nicht, wie man sonst an die Requestdaten des Clients kommt. CGI soll ja _genau_ die Schnittstelle zwischen Request, wie er beim Webserver ankommt und dem Script und dort wird bekannterweise nicht der gesamte Request abgebildet.
Wie Daniel wäre ich natürlich auch an einer Lösung interessiert.Viele Grüsse
Philipp
-
-
-
-
-
-