htaccess und Skriptnamen

[Rouven]

Hallo,

ich muss mal gerade die Apache-Experten zu Hilfe rufen. Ich hab ein Problem mit der Einrichtung eines Verzeichnisschutzes über htaccess.
Umgebung:
Apache2 auf Windows XP Pro SP2, nachinstalliertes Modul "mod_auth_sspi" für die interne Windows-Authentifizierung. Als Skriptsprache wird IBM Net.Data als cgi verwendet.
Ich glaube das Problem liegt in der Namensstruktur der Makros. Folgender Auszug aus dem Logfile des Apache:
127.0.0.1 - TSD_CLIENT_3\Rouven [31/May/2005:23:47:40 +0200] "GET /test.d2windex HTTP/1.1" 404 307
OK, was ich hier aufgerufen habe ist eine Datei, die es nicht gibt. Der Server hat dennoch meine Anmeldung am Rechner mit dem Benutzernamen zur Kenntnis genommen.
127.0.0.1 - - [31/May/2005:23:47:43 +0200] "GET /test.d2w/index HTTP/1.1" 401 497
Das hier ist der eigentliche Makroaufruf. Wer jetzt irritiert guckt: Im htdocs-Verzeichnis liegt eine Datei namens test.d2w. Die d2w-Erweiterung ist der cgi-Anwendung zugeordnet. Net.Data arbeitet so, dass es sich den Makronamen schnappt und in dem Makro nach einem Skriptblock (man schreibt da mehrere in ein Makro rein) namens "index" sucht. Nur ich sehe was anderes: Der Server hat die Authentifizierung nicht durchgeführt.
Hat jemand eine Idee, wo die htaccess-Datei liegen muss, damit er das trotzdem abfragt?

MfG
Rouven

[Christoph Schnauß]

hallo Rouven,

Ich glaube das Problem liegt in der Namensstruktur der Makros. Folgender Auszug aus dem Logfile des Apache:
127.0.0.1 - TSD_CLIENT_3\Rouven [31/May/2005:23:47:40 +0200] "GET /test.d2windex HTTP/1.1" 404 307
OK, was ich hier aufgerufen habe ist eine Datei, die es nicht gibt.

Sieht man daran, daß du eine 404 zurückbekommen hast.

Der Server hat dennoch meine Anmeldung am Rechner mit dem Benutzernamen zur Kenntnis genommen.

Das kann er nicht verhindern.

127.0.0.1 - - [31/May/2005:23:47:43 +0200] "GET /test.d2w/index HTTP/1.1" 401 497
Das hier ist der eigentliche Makroaufruf.

Ja, aber du bekommst eine 401 zurück (zugangsgeschützt, siehe http://de.selfhtml.org/servercgi/server/httpstatuscodes.htm#uebersicht

Der Server hat die Authentifizierung nicht durchgeführt.

Korrekt.

Hat jemand eine Idee, wo die htaccess-Datei liegen muss, damit er das trotzdem abfragt?

"/test.dsw" ist nach deinem posting ein Verzeichnis. Das taucht einmal als "test.dswindex", und ein andermal als "test.d2w/index" auf. Du solltest dich für einen Namen entscheiden.

Grüße aus Berlin

Christoph S.

[Rouven]

N'Abend,

"/test.dsw" ist nach deinem posting ein Verzeichnis. Das taucht einmal als "test.dswindex", und ein andermal als "test.d2w/index" auf. Du solltest dich für einen Namen entscheiden.

Ja, nein, den ersten Aufruf hab ich gemacht um zu zeigen was passiert wenn ich direkt auf das Verzeichnis zugreife. Ich kann auch ein index.html reinlegen, dann krieg ich die Seite angezeigt und die Authentifizierung wird ausgeführt. Das Problem ist, die untere Angabe ist "richtig". Wenn ich statt einer .html-Datei ein Net.Data-Makro aufrufe, bin ich meines Wissens an die Konvention "makroname.d2w/blockname" gebunden. Im Verzeichnis liegt nur makroname.d2w. Das wird an das CGI-Modul übergeben und der sucht sich in der Datei den Blocknamen. Den Webserver scheint aber plötzlich die Authentifizierung nicht mehr zu interessieren.

MfG
Rouven

[Christoph Schnauß]

hallo Rouven,

Wenn ich statt einer .html-Datei ein Net.Data-Makro aufrufe, bin ich meines Wissens an die Konvention "makroname.d2w/blockname" gebunden.

Ich kenne diese "Konvention" nicht so genau. Aber es ist vermutlich so, daß du durch den Punkt im Dateinamen ganz einfach woanders hingelangst.

Im Verzeichnis liegt nur makroname.d2w. Das wird an das CGI-Modul übergeben

Und wirkt dann als Pfadname.

Den Webserver scheint aber plötzlich die Authentifizierung nicht mehr zu interessieren.

Ganz im Gegenteil. Er sucht nur nach der htaccess in einem (nicht existierenden) Unterverzeichnis bzw. in einer Subdomain.

Grüße aus Berlin

Christoph S.

[Rouven]

Ganz im Gegenteil. Er sucht nur nach der htaccess in einem (nicht existierenden) Unterverzeichnis bzw. in einer Subdomain.

Ja, hmh, genau das fürchte ich auch. Nur ich weiß nicht, wie ich aus der Nummer wieder rauskomme. Es gibt noch die möglichkeit anstelle des Makros die cgi-Exe direkt anzusprechen, so nach dem Motto "/cgi-bin/db2www.exe/makroname.d2w/blockname". Bewirkt das selbe, kommt auch das selbe raus. Hab eine .htaccess im cgi-bin Verzeichnis liegen gehabt (ok, keine Ahnung, ob das überhaupt funktioniert), Ergebnis war das selbe.

MfG
Rouven

[Sven Rautenberg]

Moin!

Den Webserver scheint aber plötzlich die Authentifizierung nicht mehr zu interessieren.

Ganz im Gegenteil. Er sucht nur nach der htaccess in einem (nicht existierenden) Unterverzeichnis bzw. in einer Subdomain.

Nein, der Apache sucht grundsätzlich den gesamten Verzeichniszweig bis hin zum Ziel nach .htaccess-Dateien ab und wendet deren Konfigurationen an.

• Sven Rautenberg

[XaraX]

Hallo,

Den Webserver scheint aber plötzlich die Authentifizierung nicht mehr zu interessieren.

Ganz im Gegenteil. Er sucht nur nach der htaccess in einem (nicht existierenden) Unterverzeichnis bzw. in einer Subdomain.

Nein, der Apache sucht grundsätzlich den gesamten Verzeichniszweig bis hin zum Ziel nach .htaccess-Dateien ab und wendet deren Konfigurationen an.

nein, der Apache (zumindest ein gerade getesteter 2.0.53 auf Linux) sucht grundsätzlich nur ab dem Verzeichnis, das durch Direktive "AllowOverride (AuthConfig|FileInfo|Indexes|Limit|Options|All)" ein Ändern der Konfiguration mittels üblicher ".htacces" zuläßt und wendet diese in Abfolge an.

Gruß aus Berlin!
eddi

[XaraX]

nein, der Apache (zumindest ein gerade getesteter 2.0.53 auf Linux) sucht grundsätzlich nur ab dem Verzeichnis, das durch Direktive "AllowOverride (AuthConfig|FileInfo|Indexes|Limit|Options|All)" ein Ändern der Konfiguration mittels üblicher ".htacces" zuläßt und wendet diese in Abfolge an.

Bevor das wieder auseinandergebaut wird; dies trifft auf die gewöhnliche Konfiguration zu:

  
<Directory />  
    # The server can be made to avoid following symbolic links,  
    # to make security simpler. However, this takes extra CPU time,  
    # so we will just let it follow symlinks.  
    Options FollowSymLinks  
  
    # Don't check for .htaccess files in each directory - they slow  
    # things down  
    AllowOverride None  
</Directory>  

Gruß aus Berlin!
eddi

[Sven Rautenberg]

Moin!

nein, der Apache (zumindest ein gerade getesteter 2.0.53 auf Linux) sucht grundsätzlich nur ab dem Verzeichnis, das durch Direktive "AllowOverride (AuthConfig|FileInfo|Indexes|Limit|Options|All)" ein Ändern der Konfiguration mittels üblicher ".htacces" zuläßt und wendet diese in Abfolge an.

Ok, ist natürlich korrekt, eine "normale" Konfiguration erlaubt .htaccess allerdings üblicherweise auch im DOCUMENT_ROOT, mindestens ab dort bis hin zum gewünschten Unterverzeichnis wird dann aber .htaccess wirksam.

• Sven Rautenberg

[Sven Rautenberg]

Moin!

Ich glaube das Problem liegt in der Namensstruktur der Makros. Folgender Auszug aus dem Logfile des Apache:
127.0.0.1 - TSD_CLIENT_3\Rouven [31/May/2005:23:47:40 +0200] "GET /test.d2windex HTTP/1.1" 404 307

Das kann nicht dein erster Aufruf einer URL auf dem Server gewesen sein, du mußt dich vorher schon mal dort angemeldet haben - sonst hätte dein Browser nicht schon direkt die Credentials mitgeschickt IMO.

127.0.0.1 - - [31/May/2005:23:47:43 +0200] "GET /test.d2w/index HTTP/1.1" 401 497

Was für eine Reaktion zeigt dein Browser hier?

• Sven Rautenberg

[Rouven]

Hi,

127.0.0.1 - TSD_CLIENT_3\Rouven [31/May/2005:23:47:40 +0200] "GET /test.d2windex HTTP/1.1" 404 307

Das kann nicht dein erster Aufruf einer URL auf dem Server gewesen sein, du mußt dich vorher schon mal dort angemeldet haben - sonst hätte dein Browser nicht schon direkt die Credentials mitgeschickt IMO.

Doch, der Witz von dem eingebundenen Modul -> Integrated Security oder NTLM oder was auch immer der Name von dem Verfahren ist. Bei dem Protokoll (eigentlich IE vs. IIS) schickt der Browser nach Aufforderung automatisch die Windows-Anmeldung an den Webserver. Genau das sollte hier passieren.

127.0.0.1 - - [31/May/2005:23:47:43 +0200] "GET /test.d2w/index HTTP/1.1" 401 497

Was für eine Reaktion zeigt dein Browser hier?

Tja, er zeigt die Seite an...

MfG
Rouven

[Rouven]

Hallo,

so, Problem ist vorerst gelöst. Hab gerade in der httpd.conf eine Directory-Anweisung für cgi-bin gefunden. Nachdem ich die Anmeldeanweisung dort reingesetzt habe, haben sich die Skripte auch korrekt angemeldet.
Einzig negative Seite ist natürlich, dass die Einschränkung jetzt auf alle cgi-Module gilt, nicht nur für eine bestimmte Menge an Skripten. Kann man das vielleicht noch irgendwie auf eine bestimmt .exe oder irgendwas einschränken?

Na ja, für's erste reichts.

MfG
Rouven

[Sven Rautenberg]

Moin!

so, Problem ist vorerst gelöst. Hab gerade in der httpd.conf eine Directory-Anweisung für cgi-bin gefunden. Nachdem ich die Anmeldeanweisung dort reingesetzt habe, haben sich die Skripte auch korrekt angemeldet.
Einzig negative Seite ist natürlich, dass die Einschränkung jetzt auf alle cgi-Module gilt, nicht nur für eine bestimmte Menge an Skripten. Kann man das vielleicht noch irgendwie auf eine bestimmt .exe oder irgendwas einschränken?

Unabhängig davon, ob es evtl. möglich wäre, vielleicht mit einem <Files>-Container die Anmeldung zu konfigurieren, halte ich die Trennung von anmeldepflichtigen Skripten und öffentlichen Skripten per Verzeichnistrennung für eine gute Idee. Das bedeutet für dich allerdings, dass du die Pfade entweder der geschützen oder offenen Skripte verändern mußt - allerdings: Da die geschützten Skripte ja ohnehin über eine virtuelle URL aufgerufen werden, dürfte diese Veränderung die einfacher realisierbare sein. An der Browser-URL ändert sich dann nichts, nur die Skripte befinden sich dann in cgi-secure statt cgi-bin (wobei der wirkliche Name vollkommen uninteressant ist).

• Sven Rautenberg