Post ID aus URL ableiten

Saphod

Hallo!

Ich habe folgendes Problem:
Über den "init" Action Hook möchte ich bestimmte IPs blocken, weil man dort einfach mehr Informationen über die URL erhält als bei "template_redirect" (manche Aufrufe gelangen gar nicht bis template_redirect)...

Die Post ID (falls ein Post besucht wurde) erhalte ich da aber leider noch nicht, weil $wp_query noch nicht initialisiert ist.

Aber: ich habe ja die URL und somit den Permalink.

So weit, so gut. Die URL alleine hilft mir aber nichts. Gibt es in WP eine Funktion, die für eine Permalink-URL die Post ID zurückgibt??? Dann wäre ich all meine Sorgen los! :-)

Post-Statistiken kann man zwar über template_redirect auch erstellen, da gibt's dann auch $wp_query (und Zugriff auf die Post ID via $wp_query->post->ID)... aber IPs möchte ich so früh wie möglich blocken und trotzdem deren Post ID feststellen, damit ich eine Statistik erstellen kann ("xyz Zugriffe auf [Post ID] geblockt").

Hoffe, man versteht, was ich meine... :confused:

Für andere Vorschläge (z.B. ein Hook, der dazwischen liegt) bin ich natürlich auch dankbar.

Hab das Problem auch schon im wordpress.org-Forum eingestellt, aber leider noch keine Antwort erhalten.

Vielen Dank im Voraus!

Werbepost

Hallo!

Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
✔️ Deutsche Server & DSGVO-konform
✔️ Persönlicher Support (kein 0815-Ticket-System)

Mehr erfahren

jottlieb

Meine Idee soweit: Einfach in der Datenbank nachschauen...da ist ja der postslug, also Permalinktitel hinterlegt. Damit sollte sich dann auch die ID herausfinden lassen. Zusätzlich (ein Titel könnte ja mal doppelt sein), kann man ebenfalls noch einen Teil des Datums vergleichen.

Also nochmal im Klartext: In der Datenbank einfach die ID vom Post ausgeben lassen wo der Titel vom Permalink zutrifft.

Putzlowitsch

Vielleicht tut es ja auch die Funktion url_to_postid aus der rewrite.php

Gruß
Ingo

Saphod

Zitat von jottlieb

Meine Idee soweit: Einfach in der Datenbank nachschauen...da ist ja der postslug, also Permalinktitel hinterlegt. Damit sollte sich dann auch die ID herausfinden lassen. Zusätzlich (ein Titel könnte ja mal doppelt sein), kann man ebenfalls noch einen Teil des Datums vergleichen.

Danke, da habe ich auch schon dran gedacht. Ich halte das aber für nicht sinnvoll, da man dann immer genau auslesen muss, wie die Permalink-Struktur des Blogs ist, und dann per RegEx den Titel aus der URL herauslösen etc. Das ist m.E. zu kompliziert...

Zitat von Putzlowitsch

Vielleicht tut es ja auch die Funktion url_to_postid aus der rewrite.php
Gruß
Ingo

Das hört sich gut an!
Muss ich mal testen.
Danke!

[Edit1]
Hier der Code der Funktion (die Site ist übrigens Anlaufstelle No. 1):
PHPXref.com - WordPress 2.5 - /wp-includes/rewrite.php source
Klingt viel versprechend...

[Edit2]
Hmmm... kann ich innerhalb von "init" wohl noch nicht verwenden, weil ich denke, dass da "wp" und so weiter noch nicht initialisiert sind. Das ist aber egal: loggen kann ich ja die URL. Umformen kann ich es ja dann im Admin-Panel... obwohl es mir lieber wäre, gleich die Post-ID in die Datenbank zu schreiben... mal schauen... Vorschläge sind willkommen...

codestyling

Ich verstehe das Problem nicht. Wenn du öffentliche Blog Url's monitoren und sperren willst, geht das doch einfach:

PHP

add_action('template_redirect', 'my_template_redirect');


function my_template_redirect() {
    global $post;
    if(is_single() && ($post->comment_status == 'open')) {
        //... hier werden die Kommentarscripts bei mir vorbereitet, im Beispiel mit prototype.js
        wp_enqueue_script('prototype');    
    }
}

Du brauchts doch nur den Zugriff auf den bereits ermittelten Post. Ich weise WP hier an, für Einzelseiten, auf denen Kommentare erlaubt sind, zusätzliche Javascripts mit auszuliefern.
Genauso kannst du an dieser Stelle die $post->post_ID besorgen und anhand der IP machen, was du willst. Für Bilder, die direkt ausgeliefert werden, hast du so keine Chance und im Admin Bereich gibts keine post ID.

Saphod

Zitat von codestyling

Ich verstehe das Problem nicht.

OK, ich versuche es noch einmal zu erklären, was ich vorhabe - ist im Grunde genommen ganz simpel.

Das Plugin soll SO FRÜH WIE MÖGLICH (also via "init" Hook) die Zugriffe auf das Blog loggen. So kann ich erkennen, ob z.B. auf die wp-pass.php zugegriffen wurde, um einen Exploit auzunutzen.

Versuche ich das mit "template_redirect", dann werden nur halb so viele Zugriffe geloggt wie bei "init", das habe ich schon probiert. "init" ist da einfach detaillierter, weil es sehr früh im Prozess aufgerufen wird.

OK, ich klinke mich also bei "init" ein und logge mit. Gleichzeitig übrprüfe ich die IP auf eine Blacklist (die man im Admin-Bereich verwalten können soll). Soll die IP geblockt werden, ist hier Schluss, das Plugin verabschiedet sich dann mit einem simplen "die()" oder gibt nen Link für nen Honeypot aus oder wie auch immer.

Natürlich könnte ich jetzt via "template_redirect" noch einmal alle Zugriffe auf nen Post loggen. Aber dann logge ich 2 Mal (unnötig) und kann geblockte Zugriffe nicht mehr feststellen, weil ja vorher schon abgebrochen wurde und der Request "template_redirect" gar nicht mehr erreicht.

Ich möchte in der Statistik aber gerne angeben können:
"... von ... Zugriffen auf Post #ID geblockt".

Das bekäme ich locker raus, indem ich einfach das Log, was ich bei "init()" anlege, später auswerte. Dazu brauche ich die Post-ID. Die gibt es aber bei "init()" nicht, daher kommt mir url_to_postid() ganz gelegen: einfach URL auslesen, via url_to_postid() umwandeln, in DAS SELBE LOG eintragen und fertig!

Einziges Problem:
url_to_postid() funktioniert noch nicht bei "init()"!

Stellt sich also die Frage, WANN ich per url_to_postid() die Umwandlung vornehmen kann... mittlerweile glaube ich, das geht nur zur Laufzeit, also wenn die Statistik erstellt/aufgerufen wird.

War das verständlich(er)? :-)

codestyling

Zitat von Saphod

Das Plugin soll SO FRÜH WIE MÖGLICH (also via "init" Hook) die Zugriffe auf das Blog loggen. So kann ich erkennen, ob z.B. auf die wp-pass.php zugegriffen wurde, um einen Exploit auzunutzen.

Ok, verstanden. Dann drück ich es auch mal simpel aus:

Code

www. domain . de/wp-content/plugins/google-sitemap-generator/sitemap.php

Wenn ich das direkt aufrufen lasse (geht bei jedem Plugin), dann wird die ganze WP init Show umgangen, denn wenn die direkt angesprochene PHP Datei die wp-config.php bzw. wp-settings.php nicht selbst lädt (warum auch), dann kannst du das auch so nicht monitoren!
Und Exploits richten sich nur teilweise gegen den normalen Aufrufsweg, es gibt viele, die direkte PHP Aufrufe ausnutzen. Diese bekommst du gar nicht mit!

Was du versuchst, kann bestenfalls einen Bruchteil der Zugriffe abweisen, 100% bekommst du nur mit .htaccess und Auswertung der Apache Logs hin.

Saphod

Zitat von codestyling

Wenn ich das direkt aufrufen lasse (geht bei jedem Plugin), dann wird die ganze WP init Show umgangen, denn wenn die direkt angesprochene PHP Datei die wp-config.php bzw. wp-settings.php nicht selbst lädt (warum auch), dann kannst du das auch so nicht monitoren!
Und Exploits richten sich nur teilweise gegen den normalen Aufrufsweg, es gibt viele, die direkte PHP Aufrufe ausnutzen. Diese bekommst du gar nicht mit!
Was du versuchst, kann bestenfalls einen Bruchteil der Zugriffe abweisen, 100% bekommst du nur mit .htaccess und Auswertung der Apache Logs hin.

Da gebe ich Dir vollkommen recht - das habe ich auch schon mal irgendwo gehört. Tatsache ist aber, dass ich bereits per "init" logge (durch Zufall über ein Plugin) und da einen Haufen Zugriffe sehe, die ich nicht will.

Also dachte ich mir, es wäre einfach, ein Log anzulegen, auszuwerten, die Anzahl der Zugriffe pro IP anzuzeigen, vielleicht noch die dnsbl.abuse.ch mit einzubringen. Der User entscheidet dann, ob er eine IP zukünftig blocken will etc. pp.

Ich bin mir darüber im Klaren, dass ich damit nicht alles blocke.

ABER:
Mit dem bisherigen Log und einem deny in der .htaccess konnte ich durchaus bereits einen großen Teil ausfindig machen. Ich wollte mir einfach den ständigen Eingriff in die .htaccess und das Auswerten der Logs etwas vereinfachen, indem ich den Großteil über ein Plugin abfange.

Es sollte auf keinen Fall zu einer der müßigen Debatten über den Sinn und Unsinn von Antispam-Maßnahmen bei Blogs ausarten... :-)

codestyling

Zitat von Saphod

Mit dem bisherigen Log und einem deny in der .htaccess konnte ich durchaus bereits einen großen Teil ausfindig machen. Ich wollte mir einfach den ständigen Eingriff in die .htaccess und das Auswerten der Logs etwas vereinfachen, indem ich den Großteil über ein Plugin abfange.
Es sollte auf keinen Fall zu einer der müßigen Debatten über den Sinn und Unsinn von Antispam-Maßnahmen bei Blogs ausarten... :-)

Mir ist klar, das du das vereinfachen willst. Die Lösungen, die ich auf meiner TODO Liste liegen hab, sehen etwa so aus:

Absolut alle Zugriffe werden durch eine PHP geleitet, selbst für die auf Platte befindlichen echten Dateien (Bilder etc.)
Die Standard .htaccess lässt dann keinen direkten Zugriff auf irgendeine Datei mehr zu sondern nur der Controller entscheidet, ob er das per Filetyp ausgibt (Bilder/Javascripts etc.)
Bei Installation dieses Wächter-Plugins wird eine whitelist der Files erstellt, die per require reingenommen werden dürfen (falls eine PHP direkt angefragt wurde).
Die Plugin Installationsseite wird erweitert und bekommt einen Wächter, der die whitelist anpasst, wenn man ein neues Plugin installiert oder eines deinstalliert wird.
Die Themeseite wird erweitert und bekommt ein Wächter, der Themes überwacht.

So in etwa (Prosa) stelle ich mir das vor. Das ist ne Menge Arbeit aber machbar. Einzig die Zeit dazu fehlt mir. Alles andere ist virtuelle Sicherheit.

PS: Seit heute morgen 9:00 läuft wieder eine Angriffswelle auf /wp-content/cache/ und eine PHP soll nachgeladen werden, die den Domain Account und den freien Plattenplatz zurückmelden soll. Falls zu finden auch noch den WP Benutzernamen und Passwort, falls der Cache kompromitiert werden kann.
Die Aufrufe kommen immer mit ständig wechselnder IP von Australien, Niederlanden, UK usw. Diesmal scheint ein verteiltes Netz beteiligt zu sein. Bei so was hast du zu tun, das zu sperren.

Putzlowitsch

Einfach aber wirkungsvoll, Plugin- und Cacheverzeichnis umbenennen und diese in der wp-config.php definieren:

PHP

define('PLUGINDIR', 'wp-content/s634trwe'); 
define('CACHE_PATH', dirname(__FILE__).'/wp-content/re536reb/');

Gruß
Ingo

codestyling

Zitat von Putzlowitsch
Einfach aber wirkungsvoll, Plugin- und Cacheverzeichnis umbenennen und diese in der wp-config.php definieren:
PHP
define('PLUGINDIR', 'wp-content/s634trwe'); 
define('CACHE_PATH', dirname(__FILE__).'/wp-content/re536reb/');
Gruß
Ingo

Ich hab ja kein Problem damit, weil ich den Cache nicht aktiviert hab. Nur leider sind die Bots klüger geworden und ein Test mit dem PLUGINDIR zeigt, das sie erst eine Seite abholen, darin nach bekannten Plugins per RegExp suchen und wieder den passenden Plugin Pfad haben und dann mit diesem erneut ankommen. Für den Cache könnte es helfen, für die Plugins zunehmend nicht mehr. Im Moment sind nur wenig "intelligentere" Bots aktiv aber das wird zunehmen.

Putzlowitsch

Mag sein, bei mir hat es zumindest bisher die alle Zugriffsversuche erfolgreich abgewehrt. Und so ein kluger Bot ist bei mir bisher noch nicht aufgeschlagen.
Es ist sowieso immer ein Wettlauf der Seiten, wenn die andere Seite was verbessert hat, muß man halt nachziehen.

Gruß
Ingo

Willkommen! Melden Sie sich an oder registrieren Sie sich.

Post ID aus URL ableiten

Jetzt mitmachen!