Verfasste Forenbeiträge

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)
  • Thread-Starter lud3r

    (@lud3r)

    Hallo nochmal !

    Auch wenn es etwas mehr Zeit benötigt hat … doch die Lösung möchte ich hier trotzdem noch hinterlassen.

    Es lag tatsächlich daran, dass die wp-config nicht im Stammverzeichnis gelegen hat. Ich hatte diese ja eine Ebene tiefer gesetzt aus Sicherheitsgründen.
    Sie liegt nun also dort, wo auch die normeln wp-Ordner usw aufbewahrt sind.
    php läuft auf 8.1. nun *top*

    Vielen Dank für die Hinweise und Unterstützung hier !

    Thread-Starter lud3r

    (@lud3r)

    Ich wollte nicht die wp-config´s „tauschen“. Hatte ich mich wohl unklar ausgedrückt.

    Thread-Starter lud3r

    (@lud3r)

    Ich merke schon, dass Ihr echt nen Plan habt im Gegensatz zu mir mit meinem gefährlichen Halbwissen 🙂

    Auch Dir vielen Dank für Deine ausführliche Erweiterung zu den geschriebenen Dingen von Torsten.

    Es erschließt sich mir bisher also einzig die Möglichkeit, dass wirklich die wp-config mit den gegeben Beschränkungen nicht eingelesen werden konnte.
    Meint Ihr, dass es nun einen Versuch wert sein sollte die wp-config in das Hauptverzeichnis zu legen (von Internetseite A) und dann die php-Version umzustellen ? Wenn ja, dann welche Einstellungsvariante für open_basedir ?
    Ich würde natürlich vorher ein backup machen von Datein und Datenbank.
    Mit den beiden Dingen sollte ich doch alles wiederherstellen können ? Egal was schief geht. Auch wenn ich das noch nie vorgenommen habe.

    Oder sollte ich vorher soetwas wie UpdraftClone nutzen um zu testen, ob meine Seite weiterhin funktioniert und kann ich da solche Dinge überhaupt austesten wie bei mir vermutet ? Also wenn die wp-config im Vorverzeichnis liegt.
    An den Dateiattributen von 400 kann es nicht liegen ?

    Das die Seite weiss ist … von Internetseite B.
    Liegt es nicht daran, dass Datenbank leer ist? 0 Tabellen etc.
    Achso, also füge ich diese Konstante nun mit WB_DEBUG in die wp-config ein und sehe dann die aktuellen Probleme … das werde ich testen.

    Thread-Starter lud3r

    (@lud3r)

    Vielen Dank für die Hinweise, Torsten 🙂

    Dann frage ich mal anders :
    Ich hatte für die Variable open_basedir zwei Möglichkeiten :

    1. {DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp (standard) – (diese wählte ich auch)
    2. {WEBSPACEOOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions

    Das liest sich für mich wie Hieroglyphen, auch wenn ich mir gerade die php-Definition durchgelesen habe.

    Allgemein stellt sich mir die Frage, wann und wieso WordPress auf die Idee bzw. den Weg geht die Datenbankdaten abzufragen. Passiert das denn, wenn er keinen Zugriff auf die wp-config Datei bekommt ?
    Kann man es ggf. aus dem Winkel heraus betrachten ?
    Oder sollte ich mal in andere Configs von WOrdpress schauen und suchen, ob da ggf. bestimmte Dinge sind die diese Umstellung verhindern ?

    Ich habe ein komplettes Plesk-Backup, doch er kann komischerweise dieses nicht wiederherstellen. Doch … die Internetseite B liegt mir laaaange nicht so am Herzen, weswegen ich nicht einfach die Seite A umstellen möchte von der php-Version.

    Thread-Starter lud3r

    (@lud3r)

    Ich habe die Lösung gefunden und hier hinein geschrieben :

    Lösung

    Thread-Starter lud3r

    (@lud3r)

    Ich habe die Lösung nun endlich gefunden.
    In der Accesslog vom Apache war zu finden, dass wenn die Hauptseite aufgerufen wird, ein Fehlercode 401 erscheint :

    „GET /wp-admin/js/password-strength-meter.min.js?ver=5.2.4 HTTP/2.0“ 401 381 „[entfernt]“ „Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0“ „Traffic IN:84 OUT:463“ „ReqTime:0 sec“

    Ich musste in die .htaccess file im wp-ordner :

    <Files admin-ajax.php>
    Require all granted
    </Files>

    und

    <Files password-strength-meter.min.js>
    Require all granted
    </Files>

    einfügen.
    Bisher klappt es. Ich habe es auch reproduziert. Wenn es auch einige Verzögerung erfordert. Ich testete es immer im privaten Fenster im Firefox. Diese Einstellungen gelten für einen Apacheserver ab Version 2.4.

    Bis einschließlich Version 2.3 muss man dieses verwenden :

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

    und

    <Files password-strength-meter.min.js>
    Order allow,deny
    Allow from all
    Satisfy any
    </Files>

    Bisher klappt es bei mir mit dem 2.4. Schnipsel.
    Ich hoffe, dass ich anderen damit helfen kann.

    Vielen Dank für die Unterstützung hier im Forum (ich war ja schon im anderen Thread aktiv) ! Das ist wirklich sehr nett, dass hier so individuell auf einzelne Fragen eingegangen wird.

    Thread-Starter lud3r

    (@lud3r)

    Zum zweiten mal vielen Dank für die rasche Antwort!

    Der Passwortschutz ist „standard“ realisiert per htaccess. Natürlich kann ich die paar zeilen auch einfügen, jedoch ist das nicht die Ursache. Leider.
    Der Systempfad ist richtig und die Authentifizierung auch funktionell sobald ich das Plugin woocommerce deaktiviert habe. Ich war überrascht und bis ich das heraus fand hat es auch gedauert.
    Sobald die Deaktivierung des Plugins woocommerce der Fall ist, arbeitet die Abfrage der Authentifizierung per htaccess ganz normal bzw. wie gewohnt.

    Ich habe bereits zwei andere Forenbeiträge gefunden die das gleiche Problem haben, jedoch gibt es auch da keine Lösung für. Ich suche bereits intensiv.

    Forumeintrag 1

    Forumeintrag 2

    Grüße

    Thread-Starter lud3r

    (@lud3r)

    Nun muss ich also bei woocommerce mal anklopfen 😉 Normal kann das so ja nicht geschehen, denn das Plugin nutzen ja nicht nur 25 Personen.

    Thread-Starter lud3r

    (@lud3r)

    Ursache gefunden!

    Ich habe in jeglicher Form htaccess verändern. Ohne Erfolg.
    Anschließend fand ich heraus, dass wenn das Woocommerce-Plugin aktiv ist dieses Problem auftritt.
    Bedeutet, dass wenn WC als Plugin aktiviert ist, erfolgt die htaccess-Abfrage auf der Start-/Hauptseite.
    Weshalb auch immer.

    • Diese Antwort wurde geändert vor 4 Jahren, 7 Monaten von lud3r.
    Thread-Starter lud3r

    (@lud3r)

    Da gebe ich Dir Recht mit den Sicherheitslücken, dass besonders „alte Systeme“ anfälliger sind.

    Ich werde das mit dem privaten Browserfenster prboeren und dann eine Rückmeldung geben.

    Andere Frage : Gibt es noch eien andere Möglichkeit einen derartigen htaccess-Schutz zu realisieren. Z.B. ein Plugin ?

    Und weitere Frage : Angenommen ich schütze nun die wp-login.php durch die htaccess-datei im Hauptordner. Ist das trotzdem noch funktioniell, wenn der Adminlogin umbenannt wurde (so wie Du es vorhin auch vorgeschlagen hast). Ich shcätze zwar ja, weil es ja eigentlich nur eine Maske ist die Umbenennung, oder ?

    Und wonach sollte ich als Schlagwort suchen, wenn diese htaccess-Schutzvariante sich nicht beheben lässt. Mir fällt da kein Schlüsselwort ein. Oder bei meinem webhostinganbieter direkt nachfragen ? Der wird mir doch bestimmt sagen, dass ich das richtig konfigurieren muss 😀

    Thread-Starter lud3r

    (@lud3r)

    Vielen Dank dafür bzw den Link.
    Diese und andere Einstellungen sind bereits in der htaccess vorhanden.

    Speziell wird ja dort geschildert, dass man der htaccess (die nicht im wp-admin Bereich liegt, sondern im Hauptordner) Einstellungen hinzufügt, dass man den Zugriff auf die wp-login.php verhindert. (Ist auch funktionell, wenn man den Loginbereich von wp-admin umbenannt hat, oder ?
    Diese Einstellungen habe ich auch bereits probiert, jedoch tut sich dann „gar nichts“ bzw es wird dann, wenn ich den Adminbereich aufrufe, keinerlei htaccess-Abfrage gestartet.

    Ich habe auch bereits den Adminbereich umbenannt wie gesagt 🙂
    XML-RPC ist ebenfalls abgeschaltet.

    Ich möchte nur nicht, dass jemand den Adminbereich versucht anzugreifen und der htaccess ist schon echt eine normal „super-einfache“ und effektive Methode.

    Thread-Starter lud3r

    (@lud3r)

    Ja, die habe ich angelegt und das funktioniert auch, wenn ich Benutzer und Passwort eingebe.

    Richtig. Nur weil es eben meine WordPressinstallation betrifft bzw speziell den wp-admin Bereich, habe ich das hier hinein geschrieben.

    – evtl verursacht das woocommerce, weil auf der Hauptseite ein Einloggmöglichkeit besteht ?
    – gibt es eine andere Möglichkeit htaccess-Schutz für wp-admin zu erzeugen ?
    – andere Lösungsmöglichkeiten ?

    Grüße

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)