¿Detecta una URL de WordPress sin hacer un HTTP GET completo?

Estoy tratando de escribir una rutina de oneboxing que le dé a las entradas de blog de WordPress un tratamiento especial. Entonces, dada una URL simple y sin adornos en el contenido, como

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

¿Cómo detectaría que se trata de una instalación de WordPress, idealmente sin hacer un HTTP GET completo en cada URL que veo?

Ciertamente, hay convenciones comunes para las URL de WordPress con las que podríamos comenzar, lo que elimina al menos algunas URL de la contienda. En este caso lo es ...

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

Pero esa tampoco es una constante universal.

Intenté mirar los encabezados de esa URL usando HTTP HEAD , y veo:

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

No creo que confiar en la presencia de WP-Super-Cachesea ​​particularmente confiable, y eso es lo único que veo en los encabezados que ayudaría, así que ¿tal vez no haya encabezados HTTP comunes en una instalación de WordPress?

Según mi experiencia y búsqueda rápida de código, no hay formas deliberadas de que WP se identifique en los encabezados. Sin embargo, hay algunos que parecen lo suficientemente distintos y no es probable que se personalicen.

HEAD to /wp-login.phpcontendrá lo siguiente para la instalación de .org:

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

Y para .com:

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

El nombre de la cookie se puede personalizar mediante la definición de TEST_COOKIEconstante, pero la WP Cookie checkcadena está codificada en el núcleo, así como también se set_cookie()solicita en la fuente del archivo.

Para localizar wp-login.phphay algunos atajos de URL (implementados wp_redirect_admin_locations()desde WP 3.4 (ver ticket # 19607 ):

/loginen la raíz del sitio se 302redirige a wp-login.php, donde sea que esté.

Entonces, el único escenario que no se puede detectar de manera confiable si WP está instalado y confinado en el subdirectorio, sin ser utilizado para administrar la raíz del sitio.

Envíe una HEADsolicitud al /wp-feed.phpmismo directorio que /xmlrpc.php(incluso en instalaciones de subdirectorios). En WordPress obtendrá un Locationencabezado como respuesta que contiene la cadena feed.

En su ejemplo blog.stackoverflow.com, obtendrá:

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 existencia de un archivo xmlrpc.phpsolo no es lo suficientemente segura. Cualquiera puede dar este nombre a un archivo.

Advertencia: el X-Pingbackencabezado se puede deshabilitar filtrando 'wp_headers'. Entonces mi sugerencia no es a prueba de balas.

Relacionado: ¿ Pasos a seguir para ocultar el hecho de que un sitio usa WordPress?

Agregue la URL con ?page_id=-1y haga una solicitud HTTP HEAD para eso.

En los blogs de WordPress autoinstalados, esto dará como resultado una respuesta 404.

En los blogs de wordpress.com, esto dará como resultado una respuesta 301 (que termina en una respuesta 200 si sigue la redirección).

En los sitios que no son de WordPress, debe obtener una respuesta 200 (suponiendo que la URL original sin la cadena de consulta le haya dado un 200), la cadena de consulta no debería hacer ninguna diferencia.

Ejemplo con una solicitud HEAD para 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

Ejemplo con una solicitud HEAD para http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(siga los redireccionamientos desactivados):

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

(¡Tenga en cuenta el huevo de Pascua de X-Hacker!)

Si sigues la redirección 301 para el blog wordpress.com, terminas con esto:

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.

Tenga en cuenta el encabezado "Enlace" que contiene la http://wp.me/URL, que parece ser común a todos los blogs alojados en wordpress.com y podría usarse para identificarlos.

Creo que esto funciona porque pasar ?page_id=-1la URL anula la ruta predeterminada de los segmentos de la URL. No habrá una página con ID de -1, por lo que se servirá un 404 / redirect.

Ni wp-super-cache está disponible en todas las instalaciones de WordPress, ni hay ningún formato fijo en las URL. Si bien la página de configuración de enlaces permanentes proporciona algunas configuraciones fijas para los esquemas de URL que se pueden usar, cualquiera puede usar cualquier esquema de URL personalizado. Por ejemplo, si alguien decide usar solo el nombre de la página / publicación en la URL, es más o menos imposible determinar si se trata de un sitio web de Wordpress.

La presencia de xmlrpc se puede usar para detectar, pero nuevamente, esto se puede deshabilitar.

Y, por último, incluso si obtiene un acceso completo a la URL, aún no es 100% posible detectar si la página está construida con WordPress. Todo depende de la plantilla del tema y de cómo se desarrolle.

Una forma bastante confiable es buscar la presencia wp-login y wp-admin. Pero incluso estos también podrían ser movidos. Sin embargo, iría por este camino.

Dos alternativas a los comentarios, configura tu propio encabezado de WordPress. Suelta esto en las funciones de tu tema.php.

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

header('Type: WordPress');
}

La huella digital de escaneo WP (ruby), sigue varios pasos para tratar de averiguar si se está utilizando WordPress, como buscar el directorio del complemento, el nombre del tema, las metaetiquetas, el archivo Léame, etc. (No tengo idea de cuán preciso es realmente esto ) http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

¿Qué tal enviar una solicitud de cabecera a uno de los archivos que comienzan con el prefijo wp-? Lo ideal es mirar wp-login.php. Si existe, eso significa que el sitio web ejecuta WordPress.