Beiträge von Putzlowitsch

Zitat von formateins

...
Der Statuscode 405 ist an der Stelle exakt richtig, erfordert aber einen gezielten Einsatz (QUERY_STRING).
...

Es gibt keine HTTP-Request-Methode QUERY_STRING.
Lesen/Verstehen: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9

Der Fehler 405 zeigt eine nicht erlaubte Requestmethode an. In der Antwort sollte eine Liste der erlaubten Methoden stehen. Welche wäre das denn z.B. um Unterschied zur verwendeten GET-Methode?
Lesen/Verstehen: http://www.w3.org/Protocols/rfc2….html#sec10.4.6

Klar kann man viel mit der .htaccess und den diversen Modulen machen. Nur ist das aus meiner Sicht für das konkrete Problem keine vernünftige Lösung.
Und ja, kann natürlich eine lange Liste mit bekannten Wordpress-URL-Parametern in der .htaccess Pflegen, die sich dann auch noch durch Plugins ändern kann. Viel Spaß!

Gruß
Ingo

Kleiner Nachtrag noch zum Ausgangspost.

Bei der Beispielzeile aus der Logdatei ist das letzte Feld gar nicht der Referrer, sondern die Domain, welche aufgerufen wurde. Der Referrer steht zwischen der Anzahl übertragener Bytes und dem User-Agent, in dem Fall "-", also leer.

Daher gab es wohl die leichte Verwirrung darüber, welche Domain eigentlich geblockt werden soll. Da der Referrer leer ist, greifen da natürlich keine Regeln, die auf einen konkreten Referrer Bezug nehmen.

Gruß
Ingo

Ja, es läuft mit der aktuellen WP-Version. Das Plugin ist so simpel, es sollte auch mit zukünftigen WP-Versionen noch funktionieren, es sei denn, WP krempelt den Core komplett um.

Die Änderung in 403 ist auch kein Problem. Einfach im Quelltext die 404 durch eine 403 ersetzen. Allerdings wird dann nicht die Wordpress-Fehlerseite angezeigt. Aber der Statuscode paßt.

Gruß
Ingo

Könnten auch nur gefälschte Absender-Adressen sein.
Im Header siehst Du ja, woher die E-Mail versendet wurde (orenpalata1server.com). Falls das nicht Dein Server/Webspace ist, kamen sie woanders her.

Gruß
Ingo

Ja, sofern damit die Ausgabe erzeugt wird, sollte das reichen.

Gruß
Ingo

Zitat von formateins

...
Reduzieren wir das auf einen obligatorischen Bot, der Webseiten pushen will. Spam, Scam, einerlei. Im Fachjargon wird das als Referer-Spoofing bezeichnet.
...

Nenne es, wie Du willst, nur kommt man da mit der Auswertung des Referrers nicht wirklich weiter, wenn als Referrer die eigene Domain/Webseite eingetragen ist.
Auch die Aufnahme einer solchen URL in den Google-Index kann man so nicht verhindern, da der Google-Bot nicht mit dem gefälschten Refferer zugreifen wird.

Zitat von formateins

...
Ich würd's serverseitig lösen, dann gibt's erst garnix zu guggn und/oder Du kannst einen 405 zurück werfen.
...

Ein Statuscode 405 ist an der Stelle einfach falsch, denn die Request-Methode GET ist ja durchaus richtig. Was sollten den die richtige Methode sein, POST oder HEAD?

Man könnte eventuell als alternative zum 404 einen 403 zurückgeben, ein etwas stärkeres Signal. Der wirkt auch bei Google etwas schneller.

Gruß
Ingo

Also über ein Plugin.
Ja und welche Datei wird dort eingebunden? Die von der Liga-Verwaltung?
An irgendeiner Stelle muß dort eine Ausgabe z.B. mit der Funktion date() erfolgen und da müßte das geändert werden.

Gruß
Ingo

Zitat von r23

nö macht er nicht ...

Doch, das macht er, sneakfilm.de ist seine eigene Domain.

Das sieht mir auch nicht nach Referrer-Spam aus, denn da werden üblicherweise existierende URLs verwendet und als Referrer die Spam-Adresse angegeben. Hier wird aber als Referrer die eigene Adresse verwendet.

Gruß
Ingo

Zitat von chilidog

... - AddHandler php56-cgi .php in Deine .htaccess Datei einfügst...

Besser ist: AddHandler php5-cgi .php
Damit wir dieselbe PHP-Version verwendet, die auch als Apache-Modul läuft.

Und außerdem sollte das in eine .htaccess-Datei im wp-admin-Verzeichnis eingetragen werden und diese nach dem Update wieder gelöscht/umbenannt werden. So mach ich das zumindest.

Ich denke auch, daß es gar nicht mal unbedingt an den Schreibrechten liegt, denn Wordpress überprüft das vor dem Update und fordert ggf. zur Eingabe von FTP-Zugangsdaten auf.

Gruß
Ingo

Nicht in der functions.php im wp-includes-Ordener. Man sollte nie die WP-Core-Dateien selbst verändern.

Du mußt die Änderungen dort durchführen, wo Dein Ligeverwaltungs-Programm etwas auf einer WP-Seite ausgibt.
Wie ist denn das in Wordpress integriert? Als Plugin oder "zu Fuß"?

Gruß
Ingo

Mit der .htaccess ist das eher schwierig zu bewerkstelligen.
Es gibt dafür aber ein kleines Plugin, welches die URL-Parameter auf Vorhandensein in Wordpress prüft und ggf. den Fehlerstatus 404 setzt:
https://goo.gl/uK6Qcs

Gruß
Ingo

Wordpress akzeptiert von Hause aus erstmal alle URL-Parameter, da wird nichts geprüft.

Möglicherweise versucht jemand eine URL-Weiterleitung zu nutzen, die es auf Deiner Website aber nicht gibt.

Idealerweise wird für ungültige Parameter eine Fehlerseite und der Statuscode 404 von Wordpress zurückgegeben. Ansonsten wird auch Google diese URLs als gültig ansehen und in den Index aufnehmen.

Gruß
Ingo

Man muß das im Quelltext ändern und z.B. die PHP-Funktion date() durch die WP-Funktion date_i18n() ersetzen.

Gruß
Ingo

Meines Wissens gibt es bei All-Inkl keinen Dateimanager im Kundenmenü, ich habe zumindest noch keinen gefunden.

Gruß
Ingo

Das Problem liegt daran, daß Wordpress erstmal per date_default_timezone_set( 'UTC' ) die Zeitzone in PHP auf UTC zurücksetzt. Wenn nun die normalen PHP Datum-/Zeitfunktionen z.B. in einem Plugin genutzt werden, stimmt dadurch die Zeit nicht. Man sollte innerhalb von Wordpress die WP-eigenen Datum-/Zeitfunktionen nutzen.

Gruß
Ingo

Eventuell kannst Du auch die "Account-Übertragung" bei All-Inkl nutzen (bei Tools im Kundenbereich). Das geht für die Webspace-Daten per FTP und auch für die Datenbank-Tabellen, sofern der alte Hoster den Zugriff von außen auf die Datenbank erlaubt.

Gruß
Ingo

Zitat von KLE-Hosting

...
Beim "VDS" (VPS) Server der mit Root-"Rechten" ausgeliefert wird, hat man natürlich auch die nötigen SQL Rechte, wenn dem nicht so ist, ist was schief gelaufen einfach.

Eben, bei einem Root-Server ist man ja selbst der Administrator und deshalb auch selbst verabtwortlich für alle intstallierten Komponenten. Das wird bei allen Webhosting-Anbietern nahezu gleich aussehen. Wenn man allerdings keine Ahnung von der Server-Adminstration hat, kann aber erstmal der Bereitsteller des Servers nichts dafür, wenn estwas nicht funktioniert.

Mir ist aber immer noch schleierhaft, warum zum Anlegen von Tabllen Root-Rechte für MySQL erforderlich sein sollen. Das würde ja bedeuten, daß nicht nur WP-Multisite nicht funktioniert, sondern überhaupt keine Anwendungen, die mindestens eine Tabelle in der MySQL-Datenbank benötigen.

Man mag ja von 1&1 halten, was man will, aber das ist einfach unsinn. Es zeigt eher, daß der Nutzer keine Ahnung von Servern hat.

Gruß
Ingo

So sieht das gut aus, so sollte es funktionieren.

Gruß
Ingo

Das Redirect 301... sollte vor dem # BEGIN WordPress stehen, das hat nichts mit mod_rewrite zu tun.

Außerdem meinte ich, daß der Slash ans Ende der Ziel URL gehört, also so:

Redirect 301 /quelle.html http://example.com/ziel[B]/[/B]


# BEGIN WordPress
<IfModule mod_rewrite.c>
...

Gruß
Ingo

Wenn alle Umleitungen in der .htaccess stehen, wird das Plugin nicht benötigt. Du kannst es löschen.

Wichtig ist, wie formateins schon erwähnte, ein Redirect 301 ... oder Redirect permanent ... in der .htaccess-Datei.
Du solltest auch des abschließenden Slash bei den Umleitungszielen hinzufügen, da Du das so in Wordpress konfiguriert hast. Sonst gibt es immer zwei Weiterleitungen, eine in der .htaccess und eine von Wordpress.

Die Regeln sollten vor den Wordpress-Regeln stehen.

Gruß
Ingo