htaccess

[thobie]

Moin, Moin, Kollegen,

ich habe ein merkwürdiges Phänomen, für das ich keine Erklärung und keine Lösung habe.

Ich schütze eine zwei Sites mit einer .htaccess- und .htpasswd-Datei. Das funktioniert auch bisher gut.

Ich habe jedoch in beide Sites ein Forum (Asgaros-Forum) eingebunden. Beim Anmelden oder Registrieren greift die Site, da das Forum seine Mitglieder als WP-Benutzer mit Abonnentenrolle speichert, auf die .htaccess zu und verlangt die Zugangsdaten für den vermeintlich geschützten Adminbereich. Das ist natürlich für das Backend korrekt, für das Forum Unsinn.

Bis ich dies geändert habe (Einstellungen im Forum mit anderer Anmelde-/Registrier-URL als über die wp-config.php), habe ich jetzt vorübergehend die .htaccess-Datei mit Zusatz „-alt“ umbenannt und sie somit deaktiviert.

Das Problem: Auf einer Site funktioniert dies einwandfrei, auf der anderen verursacht dies bei allen Seiten außer der Startseite einen 404-Error. Wenn ich übrigens auf der letzteren Site die beiden Dateien lösche, habe ich den gleichen 404-Error.

Weiß jemand, wie ich dies beheben kann?

 

[ElectricWizard]

Was nutzt du für einen Webserver? Was genau wird nicht gefunden? Was sagen die Serverlogs dazu?
Wo hast du die HTTP-Authentifizierung konfiguriert? Dort solltest du es deaktivieren und nicht einfach irgendwelche Dateien umbenennen.

disclaimer: Keine Ahnung was du eigentlich tust, oder vorhast. Entweder hab ich zu wenig Kaffee, oder es ist für mich zu wirr geschrieben.

 

[Difool]

Ich habe jedoch in beide Sites ein Forum (Asgaros-Forum) eingebunden. Beim Anmelden oder Registrieren greift die Site, da das Forum seine Mitglieder als WP-Benutzer mit Abonnentenrolle speichert, auf die .htaccess zu und verlangt die Zugangsdaten für den vermeintlich geschützten Adminbereich. Das ist natürlich für das Backend korrekt, für das Forum Unsinn.

Dann würde ich vermuten, dass du das Backend mit dem Pfad /wp-admin via htaccess schützen lässt?
Es könnte nun aber sein, dass ein Plugin für das Forum Zugriff auf die /wp-admin-Ebene braucht oder will.
Teste für htaccess die Variante mit <files>

Beispiel:

# Protect the wp-config.php file
<files wp-config.php>
order allow,deny
deny from all
</files>

 

[ElectricWizard]

Ah, der Wordpressflüsterer weiß natürlich gleich Bescheid.

 

[thobie]

Moin, Moin, Difool, genau das steht in meiner .htaccess:

# Auth protect wp-login.php
<Files wp-login.php>
  AuthType Basic
  AuthName "Geschuetzter Admin-Bereich"
  AuthUserFile /xyz/.htpasswd
  Require valid-user xyz
</Files>

# Zugriff verweigern
<FilesMatch "(\.htaccess|\.htpasswd)">
  Order deny,allow
  Deny from all
</FilesMatch>

# Konfigurationsdatei schützen
<files wp-config.php>
Order allow,deny
Deny from all
</files>

 

[Difool]

Sind die im root?

Sonst müsstest du mal checken, wie der Login-Prozeß dieser Forums-Komponente funktioniert –
und ob dieser auch über die wp-login.php geht (weil du schriebst, dass die User in wp angelegt werden).
Die Abonnentenrolle in wp ist ja dann ein wp-login.
Kontrolliere mal mit einem Testuser-Login und Browser-Developertool, was da aufgerufen wird beim Login.

Möglicherweise kannst du gezielt „whitelisten“ , was benötigt wird:
Beispiel

<Files "admin-ajax.php">
Allow from all
Satisfy Any
</Files>

edit:

Meist wird für einen Login die admin-ajax.php aufgerufen.

Alternativ probiere aus, indem du eine htaccess-Datei mit Passwort-Abfrage zum Backend direkt in den Ordner wp-admin legst
und so whitelistet:

AuthType Basic
 AuthName "Protected Area"
 AuthUserFile /dein-pfad-zu/passwords/.htpasswd
 AuthGroupFile /dev/null
 Require valid-user

# This is the whitelisting of the ajax handler
 <Files "admin-ajax.php">
     Order allow,deny
     Allow from all
     Satisfy any
 </Files>
 <Files "*.css" >
    Order allow,deny
    Allow from all
    Satisfy any
 </Files>

 

[thobie]

Danke, Difool, für diese Hinweise.

ich bin jetzt einen anderen Weg gegangen.

Wie ich schrieb, will ich den geschützten Adminbereich durch die .htaccess kurzfristig aussetzen. Umbenennen oder Löschen funktioniert ja nicht, 404-Fehler, warum auch immer.

Ich habe kurzerhand den Code, der die zusätzliche Anmeldung im geschützten Adminbereich über die .htpasswd bewirkt, herausgenommen und die .htaccess wieder abgespeichert. Jetzt funktioniert das Aufrufen aller Seiten der Website und die Anmeldung/Registrierung im Forum ohne den geschützten Adminbereich.

Das Forenplugin hat in seinen Einstellungen die Option, eine spezifische Anmelde-URL und Registrierungs-URL einzugeben, damit das Plugin nicht über die wp-config.php geht und somit das (dann aktivierte) .htaccess aufruft.

So könnte ich vermutlich nur beim Anmelden/Registrieren im Forum die geschützte Adminbereichseinwahl umgehen.

Ich will dazu ein zusätzliches Plugin für Login/Register abseits desselben über die wp-config.php installieren. Ist das eine empfehlenswerte Vorgehensweise?

Das Plugin für das Forum wählt für Anmeldung/Registrierung die wp.config.php, da lässt sich sicherlich nichts whitelisten?

 

[Difool]

Ich will dazu ein zusätzliches Plugin für Login/Register abseits desselben über die wp-config.php installieren. Ist das eine empfehlenswerte Vorgehensweise?

Das wäre auch eine Alternative.
Lies dich mal bsw. ein in die Plugins, welche eine 2-Faktor-Authentifizierung (2FA) für Wordpress bieten.
Zum Beispiel Plugin: Wordfence

Oder den Defender, wenn's etwas „simpler“ sein soll.

Letztendlich gilt es da abzuwägen, ob und wie sinnvoll es ist und sein soll.
Gerade bei Benutzerrollen und Mitgliederverwaltungen ist man bei Wordpress etwas „gebunden“ - funktionell.
Lies dazu mal den Artikel (unten verlinkt [Quelle]) durch.

Das Plugin für das Forum wählt für Anmeldung/Registrierung die wp.config.php, da lässt sich sicherlich nichts whitelisten?

Naja, doch – und zwar eben dies:

 <Files "admin-ajax.php">
     Order allow,deny
     Allow from all
     Satisfy any
 </Files>

/wp-admin/admin-ajax.php

Die Datei wp-admin/admin-ajax.php ist ein wichtiges Element in jeder WordPress-Installation, ist sie doch die Basis jeder AJAX-Kommunikation. Sie wird insbesondere im WordPress-Backend für AJAX-Aufrufe genutzt, zum Beispiel wenn in der Admin-Oberfläche eines Plugins Daten nachgeladen werden sollen. Der Aufruf der admin-ajax.php wird aber auch im Frontend, also auf der eigentlichen Seite genutzt. Die Standard-Wordpress-Methode zur AJAX-Kommunikation oder allgemein zum Laden von Daten ist eben auch im Rahmen der normalen Website die Datei wp-admin/admin-ajax.php.

Quelle: https://wp-wartung24.de/wordpress-v...die-verwendung-von-wordpress-zu-verschleiern/

edit:
Ähnlich gelagerte Probleme hast du auch im Einsatz von woocommerce – wegen htaccess-password und admin-ajax.php

###
Lesen und bookmarken:
Passwortschutz für WP-Admin-Bereich

 

[thobie]

Moin, Moin, Difool,

meine wichtigen Websites sind immer vierfach gesichert:

htaccess, Benutzername/Passwort, Google reCaptcha und 2FA.

Also teste ich mal ein zusätzliches Plugin für Login/Register.

Und werde mal Deinen Code für die ajax-Datei einfügen und ebenfalls testen.

 

[thobie]

Das Whitelisten der ajax-Datei funktioniert nicht.

Entweder es gibt eine Lösung mit einem alternativen Login-/Register-Plugin. Oder die Anwendung einer .htaccess-Datei mit geschütztem Adminbereich ist bei einem Mitgliederbereich generell nicht möglich.

 

[thobie]

Ich habe ein zusätzliches Plugin für separate Registrierung/Anmeldung installiert.

Hintergrund ist derjenige, dass die Registrierung/Anmeldung im Forum bisher über die wp-config.php läuft und bei einer htaccess das neue Forenmitglied nach den Zugangsdaten zum geschützten Adminbereich gefragt wird. Natürlich völliger Unsinn.

Das Plugin UsersWP – das es glücklicherweise in einer 100%ig deutschen Übersetzung gibt – bietet Anmelde-/Register-/Passwort-verloren-/Passwort-zurücksetzen-Formulare auf jeweils einer eigenen Seite.

Beispiel: Will sich jemand im Forum registrieren, gelangt er auf die Seite www.meinesite.de/registrierung. Will er sich anmelden, auf die Seite www.meinesite.de/anmeldung. Und bekommt ein entsprechendes Formular. Dabei wird die wp-config.php umgangen. Und somit die htaccess.

Dann kam die Gretchenfrage, da ich das alles zuerst bei umbenannter, somit deaktivierter htaccess durchgeführt habe: Funktioniert auch alles MIT der htaccess?

Es funktioniert!

Bei der Anmeldung für das Backend als Admin zuerst htaccess, dann Anmeldeformular mit reCaptcha, bei Bedarf noch eine 2FA …

Bei der Registrierung/Anmeldung im Forum keine htaccess, Registrierung-/Anmeldeformular, dann das Forum und Beiträge schreiben …

Es gibt ein paar kleine Probleme. Beide Anmeldeformulare (Admin für Backend, Mitglied für Forum) haben ein eigenes reCaptcha. Das kollidiert aus irgend welchen Gründen. Aber das sollte auch behoben werden können, notfalls verzichte ich als Admin auf das reCaptcha. Dann gibt es innerhalb der Funktionen des Plugins manchmal einige Fehler, Anmeldung nach dem Registrieren über den Link in der Registrierungsbestätigung funktioniert nicht, das Anmelden im Forum dann aber doch. Aber das sind kleinere Probleme, die man auch beheben kann.

Somit scheint widerlegt zu sein, dass Websites, auf der ein Mitgliederbereich, ein Forum (oder sogar WooCommerce?) installiert ist, einen Schutz mit htaccess nicht verwenden kann.

Und wer es jetzt gerne real sehen möchte, dem schicke ich die URL gern hinterher.

 

[MacPadMan]

Statt "Basic" könnte, sofern der Server es unterstützt bzw. es aktiviert ist, auch "Digest" verwenden, nach etlichen Versuchen klappte es bei mir auch 😇

Hier ein einfaches Beispiel:
Hinweis: die Passwortdateien für "Basic" und "Digest" unterscheiden sich sehr und sind nicht miteinander kompatibel, die Passwörter müssen extra erstellt werden

Wenn du eine Ebene vom www kommen kannst, dann könntest du die .htdigestuser.pwd außerhalb des www ablegen, somit kann es nicht ohne weiteres vom www zugegriffen werden, falls die Konfiguration des Servers spinnt oder so

AuthType Digest
AuthName "Private"
AuthDigestProvider file
AuthUserFile /pfad/zum/sicheren/verzeichnis/.htdigestuser.pwd
Require valid-user

In einer Console (CLI) folgendes als Beispiel ausführen.
Bei erster Benutzung wird der Parameter -c angegeben, das steht für create (erstellen)

htdigest -c /pfad/zum/sicheren/verzeichnis/.htdigestuser.pwd "Private" Benutzername

Bei weiterer Benutzung unbedingt den Parameter -c weglassen, sonst wird die Datei neu geschrieben!

htdigest /pfad/zum/sicheren/verzeichnis/.htdigestuser.pwd "Private" Benutzername

Warum aber noch MD5 bei "Digest" verwendet wird, wäre eine andere Frage... Bei "Basic" wird wohl nur Base64 verwendet, im Prinzip wären die Passwörter in der .htpasswd im Klartext, wenn man die in Base64 decodiert

Gruppen gäbe es ja auch noch, nur habe ich mich damit noch nicht beschäftigt

Wichtig ist, dass auch die Verschlüsselung der Website 'SSL' aktiv ist, damit soll das "Abhören" vermieden werden. Es gibt dennoch Websites, die unverschlüsselt übertragen und sogar ein Bestellformular noch haben. In der heutigen Zeit muss man schon soweit es geht, hoch absichern...

---

Es gibt ein Plugin, womit man sich passwordlos einloggen kann, da eine E-Mail geschickt wird.
(Magic Login – Passwordless Authentication for WordPress)

Lesestoff

• redirect301.de/htdigest/ (weiteres zu diesem Thema)
• securityheaders.com/ (damit kann überprüft werden, ob der Header zum Beispiel in der .htaccess gesetzt ist )
• websistent.com/tools/htdigest-generator-tool/ (einfacher Generator für Digest)

Alle Angaben sind ohne Gewähr