Rilevare un URL di WordPress senza fare un HTTP GET completo?

Sto cercando di scrivere una routine di oneboxing che dia alle voci del blog di WordPress un trattamento speciale. Quindi, dato un URL semplice e senza ornamenti nei contenuti, come

http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/

Come potrei rilevare che si tratta di un'installazione di WordPress, idealmente senza fare un HTTP GET completo su ogni URL che vedo?

Esistono certamente convenzioni comuni per gli URL di WordPress che potremmo iniziare, che elimina almeno alcuni URL dalla contesa. In questo caso è ...

http://example.com/year/month/slug-goes-here

Ma questa non è nemmeno una costante universale.

Ho provato a guardare le intestazioni di quell'URL usando HTTP HEAD e vedo:

Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:18340
Content-Type:text/html; charset=UTF-8
Date:Thu, 07 Jun 2012 07:07:38 GMT
Keep-Alive:timeout=15, max=100
Server:Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Vary:Cookie,Accept-Encoding
WP-Super-Cache:Served legacy cache file
X-Pingback:http://blog.stackoverflow.com/xmlrpc.php
X-Powered-By:PHP/5.2.6-2ubuntu4.2

Non penso che fare affidamento sulla presenza di WP-Super-Cachesarebbe particolarmente affidabile, e questa è l'unica cosa che vedo nelle intestazioni che potrebbe aiutare, quindi forse ci sono zero intestazioni HTTP comuni in un'installazione di WordPress?

In base alla mia esperienza e alla rapida ricerca del codice, non ci sono modi deliberati in cui WP si identifica nelle intestazioni. Tuttavia, ce ne sono alcuni che sembrano abbastanza distinti e non sono suscettibili di essere personalizzati.

HEAD to /wp-login.phpconterrà quanto segue per l'installazione .org:

 Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

E per .com:

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wordpress.com

Il nome del cookie è personalizzabile definendo TEST_COOKIEcostante, ma la WP Cookie checkstringa è hardcoded nel core, oltre a set_cookie()richiedere questo nella fonte del file.

Per individuare wp-login.phpci sono alcune scorciatoie URL (implementate wp_redirect_admin_locations()dal WP 3.4 (vedi ticket # 19607 ):

/loginsulla radice del sito 302reindirizza a wp-login.php, ovunque si trovi.

Quindi l'unico scenario che non può essere rilevato in modo affidabile se WP è installato e confinato nella sottodirectory, senza essere utilizzato per gestire la radice del sito.

Invia una HEADrichiesta a /wp-feed.phpnella stessa directory di /xmlrpc.php(anche nelle installazioni di sottodirectory). In WordPress otterrai Locationun'intestazione come risposta contenente la stringa feed.

Nel tuo esempio per blog.stackoverflow.comotterrai:

HTTP/1.1 301 Moved Permanently\r\n
Date: Thu, 07 Jun 2012 07:30:10 GMT\r\n
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g\r\n
X-Powered-By: PHP/5.2.6-2ubuntu4.2\r\n
Location: http://blog.stackoverflow.com/feed/\r\n
Vary: Accept-Encoding\r\n
Content-Type: text/html; charset=UTF-8\r\n
\r\n

L'esistenza nuda di un file xmlrpc.phpda sola non è abbastanza sicura. Chiunque può dare questo nome a un file.

Avvertenza: l' X-Pingbackintestazione può essere disabilitata filtrando 'wp_headers'. Quindi il mio suggerimento non è a prova di proiettile.

Correlati: passi da fare per nascondere il fatto che un sito utilizza WordPress?

Aggiungi l'URL ?page_id=-1e fai una richiesta HTTP HEAD per questo.

Sui blog WordPress autoinstallati, ciò comporterà una risposta 404.

Sui blog di wordpress.com, ciò comporterà una risposta 301 (che finirà con una risposta 200 se segui il reindirizzamento).

Sui siti non WordPress, dovresti ottenere una risposta 200 (supponendo che l'URL originale senza la stringa di query ti abbia dato 200) - la stringa di query non dovrebbe fare alcuna differenza.

Esempio con una richiesta HEAD per http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/?page_id=-1:

HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Content-Encoding: gzip
Vary: Cookie,Accept-Encoding
Cache-Control: no-cache, must-revalidate, max-age=0
Last-Modified: Thu, 07 Jun 2012 08:53:01 GMT
Date: Thu, 07 Jun 2012 08:53:01 GMT
Keep-Alive: timeout=15, max=100
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Pragma: no-cache
Connection: Keep-Alive
X-Powered-By: PHP/5.2.6-2ubuntu4.2
X-Pingback: http://blog.stackoverflow.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8

Esempio con una richiesta HEAD per http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(seguire i reindirizzamenti disattivati):

HTTP/1.1 301 Moved Permanently
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Server: nginx
Expires: Wed, 11 Jan 1984 05:00:00 GMT
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
Location: http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/
Pragma: no-cache
Cache-Control: no-cache, must-revalidate, max-age=60
Connection: close
Last-Modified: Thu, 07 Jun 2012 09:01:09 GMT
Content-Type: text/html; charset=UTF-8
Date: Thu, 07 Jun 2012 09:01:09 GMT

(Nota l'uovo di Pasqua di X-Hacker!)

Se segui il reindirizzamento 301 per il blog di wordpress.com, finisci con questo:

HTTP/1.1 200 OK
Server: nginx
Vary: Accept-Encoding, Cookie
Last-Modified: Thu, 07 Jun 2012 09:48:26 GMT
Cache-Control: max-age=172, must-revalidate
Connection: close
Date: Thu, 07 Jun 2012 09:50:34 GMT
Transfer-Encoding: Identity
Content-Encoding: gzip
Link: <http://wp.me/pXGqK-27g>; rel=shortlink
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8
X-Nananana: Batcache
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

Nota l'intestazione "Link" contenente l' http://wp.me/URL, che sembra essere comune a tutti i blog ospitati da wordpress.com e potrebbe essere usato per identificarli.

Credo che funzioni perché il passaggio ?page_id=-1nell'URL sovrascrive il routing predefinito dai segmenti URL. Non ci sarà una pagina con ID -1, quindi viene invece offerto un reindirizzamento 404 /.

Né wp-super-cache è disponibile su tutte le installazioni di wordpress, né esiste un formato fisso negli URL. Mentre la pagina delle impostazioni dei permalink fornisce alcune impostazioni fisse per gli schemi URL che possono essere utilizzate, chiunque può semplicemente utilizzare qualsiasi schema URL personalizzato. Ad esempio, se qualcuno decide di utilizzare solo il nome della pagina / post nell'URL, è più o meno impossibile capire se si tratta di un sito Web Wordpress.

La presenza di xmlrpc può essere utilizzata per rilevare, ma ancora una volta, questo può essere disabilitato.

E infine, anche se ottieni un pieno accesso all'URL, non è ancora possibile rilevare al 100% se la pagina è costruita usando wordpress. Tutto dipende dal modello del tema e da come viene sviluppato.

Un modo abbastanza affidabile è cercare la presenza wp-login e wp-admin. Ma anche questi potrebbero anche essere spostati. Vorrei andare in questo modo però.

Due alternative ai commenti, imposta la tua intestazione WordPress. Rilascialo nelle funzioni.php del tuo tema.

add_action('template_redirect', 'add_wp_header');
function add_wp_header(){

header('Type: WordPress');
}

La fingerprinter di scansione WP (ruby), passa attraverso diversi passaggi per provare a capire se WordPress viene utilizzato come la ricerca della directory dei plug-in, il nome del tema, i meta tag, il file Leggimi, ecc. (Non ho idea di quanto sia effettivamente preciso ). http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Che ne dici di inviare una richiesta head a uno dei file che iniziano con il prefisso wp-. Idealmente guarda wp-login.php. Se esiste, significa che sul sito Web è in esecuzione WordPress.