Ich versuche, das Verzeichnis ~/public_html/dev mit http auth basic zu schützen, aber um das sicher zu machen, möchte ich es über ssl laufen lassen.
Der mittlere Abschnitt der Datei .htaccess wechselt zu https, wenn der Anfrage-URI mit /dev beginnt und funktioniert.
Der letzte Abschnitt der Datei funktioniert ebenfalls, funktioniert aber nicht ordnungsgemäß mit der https-Weiterleitung.
Ich möchte im Grunde http://www.example.com/dev/some_sub_dir/ eingeben und zu https://www.example.com/dev/some_sub_dir/ umgeleitet werden und zur Eingabe des http-Auth-Benutzernamens und -Passworts aufgefordert werden.
Was momentan passiert ist, wenn ich zu http://www.example.com/dev/some_sub_dir/ gehe, werde ich über Port 80 zur Eingabe eines Benutzernamens und eines Passworts aufgefordert und dann sofort erneut über Port 443 gefragt. So werden meine Zugangsdaten zweimal gesendet, einmal im Klartext und einmal verschlüsselt Making die ganze https URL umschreiben ein wenig sinnlos.
Der Grund dafür ist, dass ich nicht in der Lage sein werde, meinen Benutzer versehentlich über http zu senden; https wird immer verwendet, um auf das Verzeichnis /dev zuzugreifen.
Das .htaccess befindet sich im Verzeichnis ~/public_html/dev .
Es gibt einen relativ beliebten Hack, um HTTPS zu erzwingen, bevor die Standardauthentifizierung durchgeführt wird. Ich sah es zuerst hier:
Es beinhaltet die Verwendung eines benutzerdefinierten Fehlerdokuments, um die Ereignisse nach dem Fehlschlagen der HTTPS-Prüfung zu behandeln.
Ich habe zum Beispiel eine einzelne Seite, auf der ich HTTPS erzwingen muss, also habe ich das in einer .htaccess-Datei gemacht:
%Vor%Was bedeutet:
wenn die angeforderte Seite 'secure-page.php' ist - wenn nicht HTTPS, dann umleiten zu einer benutzerdefinierten 'Fehlerseite' - die 'Fehlerseite' ist eigentlich nur die HTTPS-Version der Seite - auf der zweiten Anfrage, Da die HTTPS-Prüfung nun bestanden wird, führen Sie Basic Auth:)
ausSie können dieses Konzept auf ein Verzeichnis oder andere Anwendungsfälle erweitern - Ihre benutzerdefinierte Fehlerseite könnte eine PHP-Seite sein, die zur korrekten HTTPS-URL weiterleitet, oder ein CGI-Skript wie im obigen Link ...
> Ich stieß auf das gleiche Problem und fand schließlich eine hässliche Lösung, aber es funktioniert. Setzen Sie die Rewrite-Regel in eine Directory-Direktive in httpd.conf oder einer Ihrer conf.d-Dateien (d. H. In der Serverkonfiguration "Main"). Setzen Sie dann die Zeilen Auth * und Require in eine Directory-Direktive innerhalb des Containers <VirtualHost _default_:443> in ssl.conf (oder wo auch immer Ihr SSL VirtualHost definiert ist).
Für mich bedeutet das, eine Datei /etc/httpd/conf.d/test.conf mit:
... und fügen Sie das folgende% cop_de% direkt über dem /etc/httpd/conf.d/ssl.conf -Tag hinzu:
Dadurch wird Apache die RewriteRule auf alle Anfragen und die Auth-Anforderungen nur auf Anfragen in der 443 VirtualHost anwenden.
Ausgehend von der Antwort von siliconrockstar füge ich ein php-Skript hinzu, das für den Fall, dass Sie SSL auf alle Dateien erzwingen wollen, und nicht nur für den Fall von siliconrockstar in einer Datei verwendet wird. Auch hier funktioniert es in Verbindung mit der htaccess-Datei.
Der htaccess zum Schutz für das gesamte Verzeichnis:
%Vor%Der php, der von htaccess aufgerufen wird (der Pfad, der in diesem Beispiel für den PHP-Port htaccess angegeben wird, ist der Stamm Ihrer Site), der https für die von Ihnen aufgerufene URL erzwingt:
%Vor%Wenn Ihre Site kein SSL-Zertifikat hat, müssen Sie eines installieren. Wenn dies Ihre einzige Verwendung ist, können Sie ein selbstsigniertes Zertifikat installieren. Auf einem cPanel VPS mit Ihrer Website auf einer dedizierten IP, die Momente zu tun braucht: in WHM, besuchen Sie
Eins. Generieren Sie ein SSL-Zertifikat und eine Signaturanforderung
dann
Zwei. Installieren Sie ein SSL-Zertifikat in einer Domäne
Der Schutz von Inhalten mit der Standardauthentifizierung funktioniert niemals sicher über HTTP.
Sobald der Benutzer seinen Benutzernamen und sein Passwort eingegeben hat, wird er unverschlüsselt für jede Seitenansicht an diese Seite gesendet - er sendet nicht nur die Zeit, zu der der Benutzer dazu aufgefordert wird.
Sie müssen Anforderungen über HTTP als nicht authentifiziert behandeln und alle über HTTPS anmelden.
Viele Websites haben HTTPS für die Anmeldung verwendet - mit Hilfe von Formularen und Cookies anstelle von Basic Auth - und gehen dann zu HTTP. Dies bedeutet, dass ihr Cookie "Sie sind eingeloggt" unverschlüsselt gesendet wird. Jedes wertvolle Ziel wurde aus diesem Grund gehackt und Google Mail wechselt jetzt zu komplettem HTTPS und andere werden folgen.
Sie haben nicht die gleichen Skalierungsprobleme wie andere, die sie von den rechenintensiven HTTPS ferngehalten haben. Wenn Ihre Homepage den HTTPS-Zugriff unterstützt, verwenden Sie sie durchgängig.
Wenn Sie die Rewrite-Regeln in die Hauptkonfiguration einfügen, außerhalb oder eines ähnlichen Vorgangs, wird das Neuschreiben vor der Authentifizierung durchgeführt.
Siehe Rewrite Tech
Ich weiß, das ist eine alte Frage, aber ich hatte Probleme mit einem einfachen ht.access Redirect. Nach vielen anderen Problemen und Antworten habe ich endlich diesen htaccess zusammengestellt, der wie vorgesehen funktioniert.
%Vor%Beachten Sie das
%Vor%Was bei vielen anderen Antworten, die ich gesehen habe, fehlte, da es Menschen direkt bei der Verwendung von https erlauben würde. Der andere Abschnitt, der in meinen Tests fehlte, war folgender:
%Vor%In diesem folgenden Snippet können Nicht-SSL-Clients für die Weiterleitung verwendet werden. Die HTTPS-Umgebungsvariable wird von der mod_ssl für SSL-Clients festgelegt.
%Vor%Ich habe zwei Antworten auf die Frage, eine mit einer Denkweise von 2010 und eine mit einer Post-2012-Einstellung.
Um diese Frage zu beantworten, als ob es 2010 war, als es gefragt wurde: Verwenden Sie zwei verschiedene VirtualHost-Konfigurationen.
Diese Lösung ist etwas außerhalb des Bereichs der Frage, da die Implikation "Ich habe nur Zugriff auf .htaccess !" In vielen Fällen ist es jedoch eine praktikable Lösung, den Administrator du jour aufzufordern, einfach zwei verschiedene VirtualHost-Konfigurationen einzurichten.
Der VirtualHost ohne SSL ist nicht für den Zugriff auf Dateien im Dateisystem konfiguriert und gibt nur 301 Weiterleitungen an https://... locations für alle Anfragen zurück.
Der SSL-fähige VirtualHost kann dann die Basisauthentifizierung implementieren, ohne befürchten zu müssen, dass der standardmäßige HTTP-Listener die Waren verschenkt.
Aber mit meinem Post-2018-Hut und der Feststellung, dass diese Frage vor Apache 2.4 gestellt wurde (Anfang 2012?), ist es Zeit für ein Update. Apache 2.4 führte <If condition> Prüfungen ein, was dies viel einfacher und direkter macht:
Erstens, IfModule die RewriteEngine nicht. Da Apache sowohl auf Port 80 als auch auf Port 443 (in der Standardkonfiguration) hört und wir SSL erzwingen wollen, möchten wir, dass der Server bricht, wenn das Rewrite-Modul anderweitig deaktiviert wird.
%Vor% Zweitens, einfach genug, führen Sie eine sofortige und permanente (301) Weiterleitung durch, wenn die Anfrage nicht sicher ist. Beachten Sie die Funktionen R (edirect) und L (ast), die zusammenarbeiten, um sicherzustellen, dass nicht verschlüsselte Anforderungen umgeleitet werden und nicht für den nicht authentifizierten Zugriff verwendet werden können. (Für die OCD, nicht kopierfreudig, beachten Sie die fehlt des Raumes zwischen != und on . Das ist beabsichtigt.)
Schließlich verwenden Sie die gleiche Variable mit einem <If-condition> Check, um sicherzustellen, dass wir nur das Passwort für die TLS-Anfrage benötigen.
Und insgesamt:
%Vor%Tags und Links apache url-rewriting .htaccess mod-rewrite http-authentication