Detectando uma URL do WordPress sem fazer um HTTP GET completo?

Estou tentando escrever uma rotina de oneboxing que dê tratamento especial às entradas de blog do WordPress. Portanto, dado um URL simples e sem adornos no conteúdo, como

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

Como eu detectaria que essa é uma instalação do WordPress, idealmente sem fazer um HTTP GET completo em todas as URLs que vejo?

Certamente, existem convenções comuns para URLs do WordPress que poderíamos começar, o que elimina pelo menos alguns URLs da contenção. Neste caso, é ...

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

Mas isso também não é uma constante universal.

Tentei olhar os cabeçalhos dessa URL usando HTTP HEAD e vejo:

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

Eu não acho que confiar na presença de WP-Super-Cacheseria particularmente confiável, e essa é a única coisa que vejo nos cabeçalhos que ajudaria, então talvez haja zero cabeçalhos HTTP comuns em uma instalação do WordPress?

Pela minha experiência e pesquisa rápida de código, não há maneiras deliberadas de o WP se identificar nos cabeçalhos. No entanto, existem alguns que parecem suficientemente distintos e que provavelmente não serão personalizados.

HEAD para /wp-login.phpconterá o seguinte para a instalação .org:

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

E para .com:

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

O nome do cookie é personalizável definindo TEST_COOKIEconstante, mas a WP Cookie checkstring é codificada no núcleo, assim como set_cookie()solicita isso na fonte do arquivo.

Para localizar, wp-login.phpexistem alguns atalhos de URL (implementados wp_redirect_admin_locations()desde o WP 3.4 (consulte o ticket nº 19607 ):

/loginna raiz do site 302redireciona para wp-login.php, onde quer que esteja.

Portanto, o único cenário que não pode ser detectado com segurança se o WP estiver instalado e limitado ao subdiretório, sem ser usado para gerenciar a raiz do site.

Envie uma HEADsolicitação para /wp-feed.phpo mesmo diretório que /xmlrpc.php(mesmo em instalações de subdiretórios). No WordPress, você receberá um Locationcabeçalho como resposta contendo a string feed.

No seu exemplo, blog.stackoverflow.comvocê obterá:

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

A existência simples de um arquivo por xmlrpc.phpsi só não é segura o suficiente. Qualquer um pode dar esse nome a um arquivo.

Advertência: O X-Pingbackcabeçalho pode ser desativado por filtragem 'wp_headers'. Portanto, minha sugestão não é à prova de balas.

Relacionados: etapas a serem tomadas para ocultar o fato de um site estar usando o WordPress?

Anexe a URL ?page_id=-1e faça uma solicitação HTTP HEAD para isso.

Em blogs WordPress auto-instalados, isso resultará em uma resposta 404.

Nos blogs wordpress.com, isso resultará em uma resposta 301 (que termina em 200 respostas se você seguir o redirecionamento).

Em sites que não são do WordPress, você deve obter uma resposta 200 (assumindo que o URL original sem a string de consulta deu 200) - a string de consulta não deve fazer diferença.

Exemplo com uma solicitação 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

Exemplo com uma solicitação HEAD para http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1(siga os redirecionamentos desativados):

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

(Observe o ovo de Páscoa do X-Hacker!)

Se você seguir o redirecionamento 301 do blog wordpress.com, terá o seguinte:

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.

Observe o cabeçalho "Link" que contém a http://wp.me/URL, que parece ser comum a todos os blogs hospedados no wordpress.com e pode ser usada para identificá-los.

Acredito que isso funcione porque a transmissão ?page_id=-1no URL substitui o roteamento padrão dos segmentos de URL. Não haverá uma página com o ID -1 e, portanto, um 404 / redirecionamento é veiculado.

O wp-super-cache também não está disponível em todas as instalações do wordpress, nem existe um formato fixo nos URLs. Enquanto a página de configurações de links permanentes fornece algumas configurações fixas para esquemas de URL que podem ser usados, qualquer um pode usar qualquer esquema de URL personalizado. Por exemplo, se alguém decide usar apenas o nome da página / postagem na URL, é mais ou menos impossível descobrir se é um site do Wordpress.

A presença do xmlrpc pode ser usada para detectar, mas, novamente, isso pode ser desativado.

E, finalmente, mesmo que você obtenha uma URL completa, ainda não é 100% possível detectar se a página foi criada usando o wordpress. Tudo depende do modelo do tema e de como ele é desenvolvido.

Uma maneira bastante confiável é procurar a presença wp-login e wp-admin. Mas mesmo estes também podem ser movidos. Eu iria por esse caminho embora.

Duas alternativas aos comentários, defina seu próprio cabeçalho no WordPress. Coloque isso em functions.php do seu tema.

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

header('Type: WordPress');
}

O WP scan fingerprinter (ruby), ele percorre várias etapas para tentar descobrir se o WordPress está sendo usado, como procurar o diretório do plug-in, o nome do tema, as meta tags, o leia-me, etc. ) http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

Que tal enviar uma solicitação de cabeçalho para um dos arquivos começando com o prefixo wp-. Idealmente, veja wp-login.php. Se existir, significa que o site está executando o WordPress.