Détecter une URL WordPress sans faire un HTTP GET complet?

J'essaie d'écrire une routine oneboxing qui donne aux entrées de blog WordPress un traitement spécial. Donc, étant donné une URL simple et sans fioritures dans le contenu, telle que

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

Comment pourrais-je détecter qu'il s'agit d'une installation WordPress, idéalement sans faire un HTTP GET complet sur chaque URL que je vois?

Il existe certainement des conventions communes pour les URL WordPress avec lesquelles nous pourrions commencer, ce qui élimine au moins certaines URL des conflits. Dans ce cas c'est ...

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

Mais ce n'est pas non plus une constante universelle.

J'ai essayé de regarder les en-têtes de cette URL en utilisant HTTP HEAD , et je vois:

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

Je ne pense pas que compter sur la présence de WP-Super-Cachesoit particulièrement fiable, et c'est la seule chose que je vois dans les en-têtes qui pourrait aider, alors peut-être qu'il n'y a aucun en-tête HTTP commun dans une installation WordPress?

D'après mon expérience et ma recherche rapide de code, il n'y a aucun moyen délibéré pour WP de s'identifier dans les en-têtes. Cependant, certains semblent suffisamment distincts et peu susceptibles d'être personnalisés.

HEAD /wp-login.phpcontient les éléments suivants pour l'installation de .org:

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

Et pour .com:

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

Le nom du cookie est personnalisable en définissant une TEST_COOKIEconstante, mais la WP Cookie checkchaîne est codée en dur dans le noyau, ainsi que l' set_cookie()appel dans la source du fichier.

Pour la localisation, wp-login.phpil existe des raccourcis URL (implémentés dans wp_redirect_admin_locations()depuis WP 3.4 (voir ticket # 19607 ):

/loginsur la racine du site 302redirige vers wp-login.php, où qu'il se trouve.

Donc, le seul scénario qui ne peut pas être détecté de manière fiable si WP est installé dans et limité au sous-répertoire, sans être utilisé pour gérer la racine du site.

Envoyer une HEADdemande /wp-feed.phpdans le même répertoire que /xmlrpc.php(même dans les installations de sous-répertoires). Dans WordPress, vous obtiendrez un en- Locationtête comme réponse contenant la chaîne feed.

Dans votre exemple pour blog.stackoverflow.comvous obtiendrez:

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

La simple existence d'un fichier xmlrpc.phpseul n'est pas suffisamment sûre. N'importe qui peut donner ce nom à un fichier.

Avertissement: l'en- X-Pingbacktête peut être désactivé par filtrage 'wp_headers'. Ma suggestion n'est donc pas à l'épreuve des balles.

Connexe: Étapes à suivre pour masquer le fait qu'un site utilise WordPress?

Ajoutez l'URL avec ?page_id=-1et faites une requête HTTP HEAD pour cela.

Sur les blogs WordPress auto-installés, cela entraînera une réponse 404.

Sur les blogs wordpress.com, cela se traduira par une réponse 301 (qui se termine par une réponse 200 si vous suivez la redirection).

Sur les sites non WordPress, vous devriez obtenir une réponse de 200 (en supposant que l'URL d'origine sans la chaîne de requête vous a donné 200) - la chaîne de requête ne devrait faire aucune différence.

Exemple avec une requête HEAD pour 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

Exemple avec une demande HEAD pour http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(suivre les redirections désactivées):

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

(Notez l'œuf de Pâques X-Hacker!)

Si vous suivez la redirection 301 pour le blog wordpress.com, vous vous retrouvez avec ceci:

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.

Notez l'en-tête "Lien" contenant l' http://wp.me/URL, qui semble être commune à tous les blogs hébergés sur wordpress.com et pourrait être utilisée pour les identifier.

Je crois que cela fonctionne parce que la transmission ?page_id=-1de l'URL remplace le routage par défaut des segments d'URL. Il n'y aura pas de page avec un ID de -1, et donc une redirection 404 / est servie à la place.

Ni wp-super-cache n'est disponible sur toutes les installations wordpress, ni aucun format fixe dans les URL. Bien que la page des paramètres de permaliens donne certains paramètres fixes pour les schémas d'URL qui peuvent être utilisés, tout le monde peut simplement utiliser n'importe quel schéma d'URL personnalisé. Par exemple, si quelqu'un décide simplement d'utiliser uniquement le nom de la page / du message dans l'URL, il est plus ou moins impossible de déterminer s'il s'agit d'un site Web Wordpress.

La présence de xmlrpc peut être utilisée pour détecter, mais encore une fois, cela peut être désactivé.

Et enfin, même si vous faites un get complet sur l'URL, il n'est toujours pas possible à 100% de détecter si la page est construite à l'aide de wordpress. Tout dépend du modèle de thème et de la façon dont il est développé.

Un moyen assez fiable consiste à rechercher la présence wp-login et wp-admin. Mais même ceux-ci pourraient également être déplacés. J'irais cependant de cette façon.

Deux alternatives aux commentaires, définissez votre propre en-tête WordPress. Déposez ceci dans le fichier functions.php de votre thème.

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

header('Type: WordPress');
}

Le WP scan fingerprinter (ruby), il passe par plusieurs étapes pour essayer de déterminer si WordPress est utilisé, comme la recherche du répertoire du plugin, du nom du thème, des balises META, du fichier lisez-moi, etc. (je n'ai aucune idée de la précision de ce fait ). http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Que diriez-vous d'envoyer une requête principale à l'un des fichiers commençant par le préfixe wp-. Regardez idéalement wp-login.php. S'il existe, cela signifie que le site Web exécute WordPress.