Passwortschutz für Ordner
Linuchs
- webserver
0 Robert B.0 Rolf B0 pl
0 Felix Riesterer0 pl
Moin,
für eine Domain bei twooit habe ich mir das Kapitel Passwortschutz durchgelesen und die Beispiele testweise übernommen.
Anstatt Passwort-Abfrage kommt de Meldung
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at webmaster@shantyfreun.de to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
In meinem FTP-Programm sehe ich das zu schützende Verzeichnis als /shantyfreun.de/sus
, aber phpinfo() zeigt mir _SERVER["PWD"] /opt/users/www/php/shantyfreun.de/
shantyfreun.de/sus/.htaccess
AuthType Basic
AuthName "sus2019"
AuthUserFile /shantyfreun.de/sus/.htusers
# AuthUserFile /opt/users/www/php/shantyfreun.de/sus/.htusers
# AuthUserFile ./.htusers
shantyfreun.de/sus/.htusers
# .htusers BenutzerDatei für Web-Projekt
Werner:$2y$05$MQ7RdCCRrKmBEDD/u4pks.9qAV8RCKy4YCP2pzgmc4lppfli41zC
Dieter:{SHA}i8xKRW2XJbkGN4UbpkXBfVjSKXs=
Heidi:$apr1$.P2k7JQX$dBcOPzzpEcQYcR0ZGw24Q0
Wie zu sehen, habe ich in der .htaccess bereits mit mehreren Ordnern experinentiert.
Mache ich was falsch oder kann ich den Ordner gar nicht schützen?
Gruß, Linuchs
Moin Linuchs,
Anstatt Passwort-Abfrage kommt de Meldung
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmaster@shantyfreun.de to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log.
Und was steht in der Server Error Log?
In meinem FTP-Programm sehe ich das zu schützende Verzeichnis als
/shantyfreun.de/sus
, aber phpinfo() zeigt mir_SERVER["PWD"] /opt/users/www/php/shantyfreun.de/
Ich denke mal, dass die Information von PHP aus dem Dateisystem des Servers korrekt ist …
shantyfreun.de/sus/.htaccess
AuthType Basic AuthName "sus2019" AuthUserFile /shantyfreun.de/sus/.htusers
… und das wäre dann diese Zeile:
# AuthUserFile /opt/users/www/php/shantyfreun.de/sus/.htusers # AuthUserFile ./.htusers
Allerdings ist es keine gute Idee, die .htusers
innerhalb des Document Root abzulegen: Durch eine Fehlkonfiguration des Servers kann es passieren, dass diese Datei per HTTP ausgeliefert wird. Das kann nicht passieren, wenn die Datei außerhalb der Document Root liegt.
shantyfreun.de/sus/.htusers
# .htusers BenutzerDatei für Web-Projekt Werner:$2y$05$MQ7RdCCRrKmBEDD/u4pks.9qAV8RCKy4YCP2pzgmc4lppfli41zC Dieter:{SHA}i8xKRW2XJbkGN4UbpkXBfVjSKXs= Heidi:$apr1$.P2k7JQX$dBcOPzzpEcQYcR0ZGw24Q0
Ich hoffe, dass du diese Passworte jetzt alle geändert hast.
Viele Grüße
Robert
Dieter:{SHA}i8xKRW2XJbkGN4UbpkXBfVjSKXs=
Heidi:$apr1$.P2k7JQX$dBcOPzzpEcQYcR0ZGw24Q0
Ich hoffe, dass du diese Passworte jetzt alle geändert hast.
Für Dieter und Heidi ohnehin notwendig. Grund: Schwache Hashes. (sha1, Apache-md5 mit 2-Zeichen-Salt)
Hallo Linuchs,
In meinem FTP-Programm sehe ich das zu schützende Verzeichnis als /shantyfreun.de/sus, aber phpinfo() zeigt mir _SERVER["PWD"] /opt/users/www/php/shantyfreun.de/
Das ist der Unterschied zwischen Remote-Sicht und Server-Sicht.
Auf dem Server befindet sich der Stammordner des Webs in /opt/users/www/php/shantyfreun.de. Auf dem Server (oder sonst wo beim Hoster) läuft ein FTP Daemon. Ich weiß nicht genau, welche FTPD-Varianten es auf Linux-Systemen gibt; aber bei ftpd kann man für einen User ein Root-Verzeichnis festlegen und man kann diesem User Verzeichnisrechte einräumen. Ich würde annehmen, dass /opt/users/www/php dein Root-Verzeichnis ist und Du von den Rechten her in diesem Ordner nur auf shantyfreun.de zugreifen darfst. Dadurch entsteht der Eindruck, du würdest mit /shantyfreun.de zugreifen. Sicherlich gibt's auch andere FTP Daemons, die anders konfigurierbar sind.
In $_SERVER['PWD'] steht der physikalische, unverfälschte Ort des Stammordners. Der würde Dir im FTP nur dann etwas nützen, wenn der Root-Ordner des Servers dein FTP Home wäre (was er hoffentlich nicht ist).
Ich bin nicht sicher, was .htaccess benötigt, aber ich würde annehmen, dass darin die Angabe von Pfaden basierend auf demjenigen Root-Ordner erforderlich ist, den der Webserver nutzt. Ich würde auch annehmen, dass eine .htusers Referenz immer relativ zu der .htaccess Datei aufgelöst wird, in der sie steht. Dazu findest Du sicherlich Hinweise in der Apache-Doku. Eine absolute Angabe von .htusers ist ganz schlecht, sowas sollte man nicht machen, damit erschwert man, dass der Web-Ordner irgendwo anders hin umgezogen werden kann.
Die Angabe von /shantyfreun.de/sus/.htusers wird aber sicherlich nicht funktionieren, das ist die Sicht des FTP-Users mit seinem Root, nicht die Sicht, die der Webserver braucht.
More information about this error may be available in the server error log.
Und? Sind sie verfügbar? Das würde Dir vielleicht sagen, was schief geht.
Rolf
Ich bin nicht sicher, was .htaccess benötigt, aber ich würde annehmen, dass darin die Angabe von Pfaden basierend auf demjenigen Root-Ordner erforderlich ist, den der Webserver nutzt.
Nein. AuthUserFile benötigt den absoluten Pfad zur Datei. MFG
Ich bin nicht sicher, was .htaccess benötigt, aber ich würde annehmen, dass darin die Angabe von Pfaden basierend auf demjenigen Root-Ordner erforderlich ist, den der Webserver nutzt.
Nein. AuthUserFile benötigt den absoluten Pfad zur Datei. MFG
Das ist soweit erst mal richtig. Aber alternativ ist die Angabe eines relativen Pfades möglich, "relativ" bezogen auf die .htaccess in welcher die Datei referenziert wird:
/opt/users/www/php/shantyfreun.de/.htaccess
kann
/opt/users/www/config/.htusers
entweder absolut (wie gezeigt) oder als
../../config/.htusers
oder auch
./../../config/.htusers
referenzieren.
Das ist mit den relativen Pfaden immer sone Sache. Stell Dir vor Du erklärst einem Besucher relativ wie der vom Banhhof zum Theater kommt, so in etwa: Nach der 3. Ampel rechts abbiegen, dann 2 Straßen geradeaus usw. Das Problem dabei: Ein Besucher muss ggf. erst den Weg zum Bahnhof finden. Sonst passt ja die Beschreibung nicht. GG
Hallo Jörg,
ich hatte schon zu einer ähnlichen Antwort angesetzt, dann aber nochmal in der Apache-Doku gestöbert und sie mir verkniffen.
Relative Angaben sind gemäß Doku nicht relativ zur .htaccess Datei, sondern relativ zum Server Root. Das ist, um beim Bahnhofsvergleich von PL zu bleiben, die DB-Netze Zentrale, und nicht der Bahnhof, in dem die .htaccess Eisenbahn steht. Oder verstand ich da Mist?
Rolf
Tach!
[...] Server Root, und das ist der Ordner in dem der Apache wohnt. Oder verstehe ich da Mist?
Das ist konfigurierbar und auch nur ein Verzeichnis, wo er seine Konfigurationsdaten findet. Dateien für Programm und Bibliotheken können anderenorts liegen.
dedlfix.
Hallo dedlfix,
okay, danke. Aber ob nun die DB-Netze Zentrale oder die DB-Netze Lagerhalle - der Bahnhof ist es nicht.
Und darum ging es doch: eine relative Angabe in .htaccess ist nicht relativ zum Speicherort der .htaccess Datei, sondern relativ zu einer zentralen Serverressource. Und wenn ich nur ein User von vielen auf dem Server bin, dann werde ich an diesem Ort keinerlei Rechte haben.
Rolf
Tach!
Und darum ging es doch: eine relative Angabe in .htaccess ist nicht relativ zum Speicherort der .htaccess Datei, sondern relativ zu einer zentralen Serverressource. Und wenn ich nur ein User von vielen auf dem Server bin, dann werde ich an diesem Ort keinerlei Rechte haben.
Das sicherlich nicht, aber du kannst davon ausgehend relative Pfadangaben nach wohin auch immer notieren. Ob das sinnvoller ist als ein absoluter Pfad, sei mal dahingestellt.
dedlfix.
Tach!
Ich bin nicht sicher, was .htaccess benötigt, aber ich würde annehmen, dass darin die Angabe von Pfaden basierend auf demjenigen Root-Ordner erforderlich ist, den der Webserver nutzt.
Nein. AuthUserFile benötigt den absoluten Pfad zur Datei.
dedlfix.
Na also da stehts doch. Ist jedoch im Übrigen nicht die Ursache für den 500er denn der kommt ja schon vorher. GGA
Hallo pl,
so isses. Und nachdem wir nun alle auf einem Stand sind, was relative Pfade in .htaccess angeht, sollten wir uns ein Bierchen schnappen und darauf warten, welchen Serverfehler uns der Shantyfreund aus dem Apache-Log herausliest. Alles andere ist Spökenkiekerei.
Rolf
Das Log ist doch völlig uninteressant, AuthBasic wird nicht unterstützt, Fertig. Im Übrigen trinke ich kein Bier. GGA
Hallo pl,
ich bin nicht so der Indianer, aber kann es nicht auch sein, dass es irgendeinen blöden anderen Fehler in der .htaccess Datei gibt, der dazu führt, dass die AuthBasic Anforderung gar nicht erst zum Zuge kommt?
Ist es denn so häufig, dass mod_auth_basic nicht geladen ist? Aber wenn das so ist, dann sollte der Fehler ja mit
<IfModule mod_auth_basic>
AuthType
...
</IfModule>
weggehen. Die Authentication ist dann zwar immer noch nicht da, aber man wüsste dann exakt, dass deine Vermutung stimmt.
Was ich mich auch frage, und mangels Blutsbrüderschaft mit Winnetou nicht weiß: Funktionieren die Auth-Direktiven außerhalb eines Blocks, der den Scope dafür festlegt (<Location>, <Directory>, <File>, etc)? Update: .htaccess ist ein gültiger Kontext für diese Direktiven, also sollte es gehen.
Rolf
Hi Rolf,
wir müssen hier bei der Problemstellung davon ausgehen daß der OP die Konfiguration des Webservers gar nicht kennt und auch gar nicht kennen muss.
Somit wäre auch eine fehlerfrei erstellte .htaccess aus der Sicht des Webservers eine fehlerhafte Konfiguration, was der OP ja letztendlich auch beschreibt. Ein Blick ins Logfile würde auch nichts anderes ergeben. GG
Tach!
Ein Blick ins Logfile würde auch nichts anderes ergeben.
Er würde zumindest einen genaueren Text zur Ursache liefern. Und das stand bereits im Text der 500er Meldung. Wenn @Linuchs nun endlich mal mit den wesentlichen Informationen rausrücken würde ...
dedlfix.
Wenn @Linuchs nun endlich mal mit den wesentlichen Informationen rausrücken würde ...
Habe keine Ahnung, wie ich an diese Information drankomme.
Linuchs
Lieber Linuchs,
Habe keine Ahnung, wie ich an diese Information drankomme.
das ist jetzt nicht Dein Ernst?! Eine Mail an Deinen Support und der Drops wäre gelutscht!
Liebe Grüße,
Felix Riesterer.
Tach!
Wenn @Linuchs nun endlich mal mit den wesentlichen Informationen rausrücken würde ...
Habe keine Ahnung, wie ich an diese Information drankomme.
Das ist schon schade, sollte man aber haben, wenn man ein Webangebot betreibt.
Es soll einige Hoster geben oder gegeben haben, die zwar ein Access-Log jedoch kein Error-Log bereitstellen. Warum auch immer, jedenfalls ist es im Apachen möglich für jeden VHost eins zu konfigurieren. Nicht für den Kunden per .htaccess, aber für den Hoster in den jeweiligen VHost-Konfigurationen. Es ist jedenfalls nicht unüblich, Error-Logs zusammen mit Access- und anderen Logs in einem allgemeinen logs-Verzeichnis für den VHost/Kunden abzulegen. Wenn du dort keins findest, solltest du dem Hoster auf den Nerv gehen, dass er dieses wichtige Hilfsmittel bereitstellt.
Ansonsten: Die öffentlich angezeigten Texte von 500er Fehlern sind absichtlich nichtssagend gehalten. Wenn man nicht Rätselraten und ewig probieren möchte, bis man eine lauffähige Konfiguration gefunden hat, muss man ins Error-Log schauen, denn da steht ein deutlicherer Hinweis auf die Ursache drin.
dedlfix.
Beispiel errorlog:
/.htaccess: Invalid command 'xAuthType', perhaps misspelled or defined by a module not included in the server configuration
Aber erstens wissen wir das schon und 2. hat er ja alles richtig geschrieben.
Aber Du kannst ja gerne mal ein Beispiel dafür bringen was im errlog steht wenn AuthType richtig geschrieben aber im Server nicht konfiguriert ist. Würde mich auch mal interessiern. GG
Tach!
Aber erstens wissen wir das schon
Wir wissen gar nichts, wir vermuten. Linuchs hat keine Bestätigung gegeben.
und 2. hat er ja alles richtig geschrieben.
Das halte ich für ein Gerücht. Einerseits zeigt er mit
phpinfo() zeigt mir _SERVER["PWD"] /opt/users/www/php/shantyfreun.de/
dass sein VHost anscheinend in diesem Verzeichnis lebt. Und dann wäre
AuthUserFile /shantyfreun.de/sus/.htusers
falsch, weil der Pfad absolut angegeben ist und somit von der Wurzel des Dateisystems ausgeht. Wenn da nicht noch ein Symlink existiert, ist zumindest die Stelle nicht richtig, wenn auch nicht unbedingt die Ursache für den derzeit ausgelösten 500er.
Aber Du kannst ja gerne mal ein Beispiel dafür bringen was im errlog steht wenn AuthType richtig geschrieben aber im Server nicht konfiguriert ist.
Das wäre müßig und bringt uns nicht weiter beim Problem. Es hilft nur, was wirklich drinsteht und nicht, was drinstehen könnte.
dedlfix.
Es gibt errlogs die sehr groß sind. Da muss man schon wissen wonach man sucht. GG
Tach!
Es gibt errlogs die sehr groß sind. Da muss man schon wissen wonach man sucht.
Zum Beispiel nach der Uhrzeit des Auftretens. Und wenn es eben erst auftrat, dann steht es ganz am Ende. Ist also nicht sonderlich schwer. Falls in den paar Sekunden zwischen Auftreten und Datei öffnen jedoch unübersichtlich viele Meldungen dazugekommen sind, oder das ErrorLog generell stark befüllt wird, dann empfiehlt es sich, die Ursache dieser Meldungen ebenfalls zu beseitigen.
dedlfix.
Tach!
Es gibt errlogs die sehr groß sind. Da muss man schon wissen wonach man sucht.
Zum Beispiel nach der Uhrzeit des Auftretens. Und wenn es eben erst auftrat, dann steht es ganz am Ende.
Nein. Nicht wenn das eine sehr gut besuchte Seite ist und sehr viele Einträge im errorlog landen. Das ist nämlich eine Erfahrung die ich gemacht habe! GG
Tach!
Es gibt errlogs die sehr groß sind. Da muss man schon wissen wonach man sucht.
Zum Beispiel nach der Uhrzeit des Auftretens. Und wenn es eben erst auftrat, dann steht es ganz am Ende.
Nein.
Also, egal, wieviel mittlerweile hinzugekommen ist, die Uhrzeit steht als ein wichtiges Kriterium im Logfile, wenn es der Hoster nicht unsinnigerweise rauskonfiguriert hat.
Nicht wenn das eine sehr gut besuchte Seite ist und sehr viele Einträge im errorlog landen.
Diesen Fall hab ich doch anschließend auch eingeräumt. Kein Grund meine Aussage komplett zu negieren.
Das ist nämlich eine Erfahrung die ich gemacht habe!
Das kann ja durchaus sein, dass du mal solche Logfiles gesehen hast, aber welche Relevanz hat das im vorliegenden Fall? Meinst du es hat gar keinen Sinn, da reinzuschauen, aufgrund deines speziellen Erlebnisses? Ja, ich habe auch schon solche Logfiles gesehen, und nein, die Tatsache, dass es solche Logfiles gibt, senkt nicht deren Bedeutung, um der Ursache für 500er auf sie Spur zu kommen.
dedlfix.
die Tatsache, dass es solche Logfiles gibt, senkt nicht deren Bedeutung, um der Ursache für 500er auf sie Spur zu kommen.
Bitte ein Beispiel! Steht Dir immer noch offen eins zu zeigen! GG
Tach!
die Tatsache, dass es solche Logfiles gibt, senkt nicht deren Bedeutung, um der Ursache für 500er auf sie Spur zu kommen.
Bitte ein Beispiel! Steht Dir immer noch offen eins zu zeigen! GG
Schreib einfach einen Vertipper in die .htaccess, so dass sich eine ungültige Anweisung ergibt und schau dir dann an, was das ErrorLog im Gegensatz zum öffentlich sichtbaren 500er Meldungstext anzeigt.
Sich (an anderer als der gezeigten Stelle) vertippt zu haben, wäre nur eine der möglichen Ursachen, einen 500er direkt beim Aufruf der Seite zu bekommen, statt erst nach Eingabe der Anmeldedaten, wenn das System versucht, eine fehlerhaft angegebene Passwort-Datei zu öffnen.
dedlfix.
Tach!
die Tatsache, dass es solche Logfiles gibt, senkt nicht deren Bedeutung, um der Ursache für 500er auf sie Spur zu kommen.
Bitte ein Beispiel! Steht Dir immer noch offen eins zu zeigen! GG
Schreib einfach einen Vertipper in die .htaccess, so dass sich eine ungültige Anweisung ergibt und schau dir dann an, was das ErrorLog im Gegensatz zum öffentlich sichtbaren 500er Meldungstext anzeigt.
Hab ich hier schon veröffentlicht
Das war aber nicht die Frage. Die steht aber auch schon da.
GG
Es soll einige Hoster geben oder gegeben haben, die zwar ein Access-Log jedoch kein Error-Log bereitstellen
Siehst Du, da sind wir wieder beim Konjunktiv. In diesem Stil könnte man ne ganze Menge schreiben! Aber keiner hat sich hier nicht einmal die Mühe gemacht nachzufragen WANN der Fehler denn auftritt. Geschweige denn auf diesen wichtigen Punkt einzugehen. GG
PS: Es soll Programmierer geben die dafür sorgen daß das errolog größer wird als das accesslog.
Tach!
Es soll einige Hoster geben oder gegeben haben, die zwar ein Access-Log jedoch kein Error-Log bereitstellen
Siehst Du, da sind wir wieder beim Konjunktiv. In diesem Stil könnte man ne ganze Menge schreiben! Aber keiner hat sich hier nicht einmal die Mühe gemacht nachzufragen WANN der Fehler denn auftritt.
Weil das ebenfalls Konjunktiv ist, solange man nicht die genaue Fehlermeldung sieht.
dedlfix.
Tach!
Es soll einige Hoster geben oder gegeben haben, die zwar ein Access-Log jedoch kein Error-Log bereitstellen
Siehst Du, da sind wir wieder beim Konjunktiv. In diesem Stil könnte man ne ganze Menge schreiben! Aber keiner hat sich hier nicht einmal die Mühe gemacht nachzufragen WANN der Fehler denn auftritt.
Weil das ebenfalls Konjunktiv ist,
Nein ist es eben nicht! Es ist eine klare Aussage des OP!
solange man nicht die genaue Fehlermeldung sieht.
Statt einer Passowrtabfrage erscheint ein status 500. Das ist weder konjunktiv noch ungenau! Das ist sogar eine sehr gute Fehlerbeschreibung mit der man was anfangen kann.
MFG
Mist. 1. Hatte ich unrecht und 2. hab auch ich gerade vergeblich versucht, einen Pfad zur .htusers relativ zum DOCUMENT_ROOT (und zur .htaccess) zu setzen. Es geht /bei mir nur mit absolutem Pfad - obwohl das in der Dok anders steht.
Tach!
Mist. 1. Hatte ich unrecht und 2. hab auch ich gerade vergeblich versucht, einen Pfad zur .htusers relativ zum DOCUMENT_ROOT (und zur .htaccess) zu setzen. Es geht /bei mir nur mit absolutem Pfad - obwohl das in der Dok anders steht.
ServerRoot nicht zu verwechseln mit DocumentRoot, das ist das wo der virtuelle Host wohnt.
dedlfix.
Ah! Also das hier:
#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the Mutex documentation (available
# at <URL:http://httpd.apache.org/docs/2.4/mod/core.html#mutex>);
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
#
#ServerRoot "/etc/apache2"
#
Ah! Also das hier:
# # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or otherwise network) # mounted filesystem then please read the Mutex documentation (available # at <URL:http://httpd.apache.org/docs/2.4/mod/core.html#mutex>); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # #ServerRoot "/etc/apache2" #
Aha. Und das soll ein Kunde wissen!? Welcher Provider gibt denn solche Informationen raus!? GGA
Tach!
Aha. Und das soll ein Kunde wissen!? Welcher Provider gibt denn solche Informationen raus!?
Das war ein Auszug aus einer Default-Konfigurationsdatei. Die kann sich jeder anschauen, der sich die Apache-Software näher anschaut. Genauso wie man sich die offiziellen Dokumentationsseiten anschauen kann. Lediglich, wo genau das ServerRoot hinzeigt, ist dem Kunden vielleicht unbekannt. Aber das braucht man nicht, weil man als einfacher Kunde üblicherweise nicht unterhalb des ServerRoot zugreifen kann. Ich sehe deshalb kein Problem damit, in der Dokummentation herauszufinden, dass man am besten eine absolute Pfadangabe verwendet, auch ohne dass man weiß, wo ServerRoot hinzeigt. Zudem gibt es viele Hoster, die eigene Hilfeseiten aufgesetzt haben, um den Kunden Beispiele für Konfigurationen bestimmter Anwendungsfälle zu geben, die auch auf die speziellen Gegebenheiten der Hoster-Konfiguration eingehen.
dedlfix.
Lieber Linuchs,
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmaster@shantyfreun.de to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log.
das kann ein Hinweis darauf sein, dass Dir Dein Hoster dieses Feature nicht anbietet. Eine Mail an den Support wäre aufschlussreicher, als eine lange Diskussion hier mit viel Herumgerate.
Liebe Grüße,
Felix Riesterer.
Interessant ist die Frage WANN der 500er erscheint. Kriegst Du den nach der Eingabe von Benutzer und Passwort oder schon vorher? MFG
PS:
Anstatt Passwort-Abfrage kommt de Meldung
Hab ich überlesen. Also kommt der 500er vorher. Und wenn das so ist, hat das nichts mit dem Pfad zur Passwortdatei zu tun. Vielmehr wird da AuthType Basic nicht unterstützt.
Aus meinem mit Apache 2.4 (sic:Version!) funktionierendem Kram:
AuthType basic
AuthName "private area"
AuthUserFile /var/www/config/.htpasswd
Require valid-user
Ich vermisse das "Require valid-user" oder etwas wie "Require user foo", "Require group bar" (+AuthGroupFile).
Wie ist denn der Server konfiguriert? Steht hinter "AllowOverride"? "All" oder "AuthConfig"?
Ich vermisse das "Require valid-user"
Wenn das fehlt kommt kein 500er sondern keine Passwortabfrage. GG
Ich vermisse das "Require valid-user" Wenn das fehlt kommt kein 500er sondern keine Passwortabfrage. GG
Warte … Testen … Das stimmt! Bleibt AllowOverride oder die falsche Adresse der .htuser als Möglichkeit (wirft beides 500er). Und natürlich der Blick ins error.log.
Ich vermisse das "Require valid-user" Wenn das fehlt kommt kein 500er sondern keine Passwortabfrage. GG Warte … Testen … Das stimmt! Bleibt AllowOverride oder die falsche Adresse der .htuser als Möglichkeit (wirft beides 500er). Und natürlich der Blick ins error.log.
Genau! Man muss sich halt einfach mal damit befassen! GG