Info für Wordpress Nutzer

[KOJOTE]

Wenn ich das heute aufspiele, muss ich dann laufende Plugins wie Limit Login Attempts Reloaded und Si Captcha Anti Spam deaktivieren oder löschen?

 

[Difool]

Wenn ich das heute aufspiele, muss ich dann laufende Plugins wie Limit Login Attempts Reloaded und Si Captcha Anti Spam deaktivieren oder löschen?

Bestenfalls "Limit Login Attempts", weil das Plugin ja dann keine Aufgabe mehr hat.

 

[ruerueka]

...
Und als Beispiel hättest du dann für die htaccess deinen absoluten Pfad zur htpasswd:
/kunden/homepages/123/df123456/htdocs/wordpress/.htpasswd
...

Ich würde die .htpasswd auf keinen Fall in das DocumentRoot legen, und auch nicht ins WP Verzeichnis.
Also nicht hier:

/kunden/homepages/123/df123456/htdocs/wordpress/.htpasswd

auch nicht hier:

/kunden/homepages/123/df123456/htdocs/.htpasswd

sondern eher hier:

/kunden/homepages/123/df123456/.htpasswd

Der Webserver kann die dann (normalerweise) trotzdem lesen.
Hintergrund: dann kann auch bei einer Fehlkonfiguration niemand einfach über Web deine Passwortdatei abziehen.

 

[Difool]

Ich würde die .htpasswd auf keinen Fall in das DocumentRoot legen, und auch nicht ins WP Verzeichnis.
Also nicht hier:

/kunden/homepages/123/df123456/htdocs/wordpress/.htpasswd

sondern eher hier:

/kunden/homepages/123/df123456/.htpasswd

Der Webserver kann die dann (normalerweise) trotzdem lesen.
Hintergrund: dann kann auch bei einer Fehlkonfiguration niemand einfach über Web deine Passwortdatei abziehen.

Da hast du sicherlich recht mit, nur bei den meisten "kleineren Web-Paketen" hast du "nur" Zugriff maximal ab:

/kunden/homepages/123/df123456/htdocs/

 

[ruerueka]

Ich habe ein (recht altes) kleines Webpaket mit PHP und mysql bei df (das damals kleinste), da geht das

 

[Difool]

Ja, bei df geht und ging (immer schon) einiges (mehr).
Wenn du in kleinen Paketen über die Verwaltungsebene des Hosters einen Ordnerschutz anlegst,
wird dir die htpasswd eine Ebene höher abgelegt – dann hat man aber keinen direkten Zugriff darauf (.htpasswd).

 

[KOJOTE]

Ich habe ManagedHosting Professional

EDIT: Der kurzen Euphorie folgt die Ernüchterung, denn jetzt stellt sich mir natürlich die Frage wo in meinem Backend ich das am besten positioniere.

 

[KOJOTE]

Guten Abend meine Damen und Herren,

heute präsentiere ich Ihnen

 

[KOJOTE]

Der vorangeganene Post entspricht natürlich meiner Gemütsfassung, nachdem ich es tatsächlich hinbekommen habe.
Vielen Dank an euch alle für die Unterstützung.

Eine Frage drückt allerdings noch ein wenig aufs Gemüt:
Wie kann ich erkennen oder prüfen, ob meine .ht-dateien auch am richtigen Platz liegen und auch nicht, so wie das @ruerueka angedeutet hat
(im Netzt finden sich auch Hinweise, dass bei falschem Ablageort die Dateien abgefangen werden könnten. Geht das auch, wenn meine Seite bereits über SSL läuft?).
Die vorhandene .htaccess habe ich einfach an Ort und Stelle belassen und geändert, somit sollte das ja wohl passen.
Die neue .htpasswd allerdings liegt mehr oder weniger im gleichen Verzeichnis, da es darunter keins mehr gibt.

EDIT: @Difool die Erweiterung der .htaccess musste ich bei mir übrigens an den Anfang der Datei stellen

 

[ruerueka]

Wie kann ich erkennen oder prüfen, ob meine .ht-dateien auch am richtigen Platz liegen

Gib die URL im Browser ein: er muss mit 403 (Forbidden) zurückgeben. Wenn du die Berechtigungen falsch gesetzt hast, kannst du den Inhalt lesen.

Geht das auch, wenn meine Seite bereits über SSL läuft?).

Klar, das ist kein Unterschied.

Die vorhandene .htaccess habe ich einfach an Ort und Stelle belassen und geändert, somit sollte das ja wohl passen.

Ja, die sollte in das Verzeichnis, das sie schützt.

Die neue .htpasswd allerdings liegt mehr oder weniger im gleichen Verzeichnis, da es darunter keins mehr gibt.

Darunter? Da haben wir wohl sprachlich andere Ansichten Ich navigiere im Dateibaum "nach oben" wenn ich in das "übergeordnete" Verzeichnis gehe. Meine Aussage im vorherigen Post war so gemeint:
/kunden/homepages/123/df123456/htdocs/
ist für den Webserver das "Document Root", d.h. alles was "darunter" (sprich: hinten drangehängt wird), ist über HTTP/HTTPS erreichbar.
Ich interpretiere den Pfadaufbau wie folgt /kunden/[Dein Auftrag]/[Deine Domain]/htdocs

Sofern du Schreibzugriff auf Verzeichnisse "darüber" hast, z.B.
/kunden/homepages/123/df123456/
solltest du die Passwortdatei dort ablegen (und natürlich den Pfad auf die Passwortdatei in deiner .htaccess-Datei anpassen).
Da kann der Webserver zum Auslesen der Passwörter zugreifen, die Datei ist aber nicht über HTTP/HTTPS erreichbar.
Natürlich kannst du die .htpasswd auch lassen, wo sie ist, sofern die Berechtigungen stimmen. Auch hier einfach den Test im Browser machen: wenn du die URL aufrufst und einen 403 Code bekommst, ist alles in Ordnung.

Falls es dich tiefer interessiert: Zum "zuhause spielen" (auch auf dem Mac hast du ja einen Webserver, mit dem man testen kann), empfehle ich: https://httpd.apache.org/docs/current/howto/htaccess.html bzw für das nächste verregnete Wochenende: http://httpd.apache.org/docs/2.4/

 

[KOJOTE]

Hallo @ruerueka und vielen Dank für deine ausführliche Antwort.
Ich steh irgendwie aufm Schlauch. Bei Eingabe welcher URL sollte es eine Fehlermeldung geben?
Wenn ich meine Seite normal aufrufe komme ich einfach auf die Seite.
Wenn ich "meine-Seite/wp-login.php" eingebe kommt die Aufforderung zur Eingabe von Benutzername und Kennwort.

 

[KOJOTE]

Gib die URL im Browser ein: er muss mit 403 (Forbidden) zurückgeben. Wenn du die Berechtigungen falsch gesetzt hast, kannst du den Inhalt lesen.

Ok, Browser neu gestartet, Webseite aufgerufen, Anmeldeaufforderung abgebrochen führt zu Fehler 401 am iMac
Nicht über iOS! Dort erscheint nach dem Abbruch keinerlei Fehlermeldung.

 

[ruerueka]

Ok, Browser neu gestartet, Webseite aufgerufen, Anmeldeaufforderung abgebrochen führt zu Fehler 401 am iMac
Nicht über iOS! Dort erscheint nach dem Abbruch keinerlei Fehlermeldung.

Nee, das meinte ich nicht. DU wolltest prüfen, ob du die .ht* Dateien korrekt geschützt abgelegt hast.
Das kannst du machen, indem du versuchtst, die .htaccess-Datei bzw. die .htpasswd-Datei im Browser aufzurufen.
Die URLs lauten in etwa (ich kenne ja deine Installation nicht):

https://www.deine-domain.de/wordpress/.htaccess
https://www.deine-domain.de/wordpress/.htpasswd

.. bitte anpassen !

Du solltest für beide Aufrufe einen 403 Fehler im Browser bekommen.
Der Fehler 401 den du bekommst, ist korrekt, er bedeutet: UNAUTHORIZED, d.h. du hast die Anmeldung abgebrochen / falsche Daten eingegeben / etc.
Was der Browser damit macht (Fehler anzeigen oder nix) ist Sache des Browsers, da halte ich mich raus

 

[KOJOTE]

Fehlermeldung erhalte ich nicht, sonst passiert aber auch nichts weiter
Habe also:
meine-domainpunkde/meinenPfadausdemFTP-Programm/.htaccess eingegeben.
Da will man mal nen Fehler und bekommt ihn nicht

EDTI: Melde ich mich jetzt unter meine-domainpunktde/wp-login.php an werde ich zuerst auf die normale Webseite geleitet (beim ersten Mal ist das jetzt immer so). Dann wiederhole ich die Eingabe mit .php und dann kann ich BNutzername und Pass eingeben. Danach werde ich auf die normale Anmeldeseite von Wordpress weitergeleitet und muss das ganze mit Eingabe der Daten wiederholen. Ist das so im Sinne des Erfinders?

 

[ruerueka]

Ich kenne WordPress nicht, aber wenn du eine Login-Seite (egal, wo die her kommt) zusätzlich mit htaccess schützt, musst du korrekterweise zweimal Zugangsdaten eingeben: einmal im Login-Popup, das der Webserver aufgrund der htaccess Anweisung aufpoppt, und dann nochmal im Formular, das WordPress zur Verfügung stellt. Die beiden Zugangskontrollen haben technisch nichts miteinander zu tun.

 

[ruerueka]

Habe also:
meine-domainpunkde/meinenPfadausdemFTP-Programm/.htaccess eingegeben.
Da will man mal nen Fehler und bekommt ihn nicht

Solange du es nicht schaffst, den Inhalt der .htaccess bzw .htpasswd im Browser anzusehen, ist alles in Butter.

 

[KOJOTE]

Ich kenne WordPress nicht, aber wenn du eine Login-Seite (egal, wo die her kommt) zusätzlich mit htaccess schützt, musst du korrekterweise zweimal Zugangsdaten eingeben: einmal im Login-Popup, das der Webserver aufgrund der htaccess Anweisung aufpoppt, und dann nochmal im Formular, das WordPress zur Verfügung stellt. Die beiden Zugangskontrollen haben technisch nichts miteinander zu tun.

Ist auch so hier, also schon mal gut (EDIT: also die zwei Zugangskontrollen)
Das mit dem 403 Fehler habe ich jetzt vor fünf Minuten auch hinbekommen. Während ich an meiner Seite angemeldet bin und bei Eingabe von
wehwehweh.meineseitepunktde/wp-admin/.htpassw erhalte ich diesen. Sollte also passen.

 

[Difool]

So, Wordpress Version 5.0 ist draussen.

Wordpress 5.0 kommt allerdings – out of the box – via Update mit dem umstrittenen Editor "Gutenberg" daher.
Ich für meinen Teil finde diesen Editor mehr als unpraktisch und visuell strikt dämlich.

Wer das WP-System-Update durchführt und auch vom neuen Editor relativ geschockt sein sollte, lade sich folgendes Plugin:

Plugin: Classic Editor

Das "Classic Editor-Plugin" kommt auch direkt vom "Wordpress-Team" – sollte also gepflegt werden.

Was haben sich die Entwickler bei diesem "Gutenberg-Editor" nur gedacht…

 

[KOJOTE]

Es gibt in der Menüzeile im Bearbeiten-Modus noch die Möglichkeit über das Einstellungssymbol, rechts neben dem Info-Zeichen, den Classic-Editor zu wählen.

 

[Difool]

Es gibt in der Menüzeile im Bearbeiten-Modus noch die Möglichkeit über das Einstellungssymbol, rechts neben dem Info-Zeichen, den Classic-Editor zu wählen.

Hat das denn bei dir nach Anwahl auch funktioniert?
Bei mir nämlich leider nicht, deswegen das Plugin dann.

Ich habe ja so einige viele Wordpress Sites "in Pflege" und da warte ich jetzt erstmal mit dem 5.0 Update.