Detectar um URL do WordPress sem fazer um HTTP GET completo?

21

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

  

enlace

Como eu detectaria que esta é uma instalação do WordPress, idealmente sem fazer um HTTP GET completo em cada URL que eu vejo?

Existem certamente convenções comuns para URLs do WordPress com as quais poderíamos começar, o que elimina pelo menos algumas URLs de contenção. Neste caso, é ...

  

enlace

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

Eu tentei ver 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-Cache seria particularmente confiável, e essa é a única coisa que vejo nos cabeçalhos que ajudaria, então talvez não haja zero cabeçalhos HTTP comuns em uma instalação do WordPress?

    
por Jeff Atwood 07.06.2012 / 09:16
fonte

6 respostas

17

A partir da minha experiência e pesquisa de código rápido, não existem formas deliberadas em que o WP se identifique nos cabeçalhos. No entanto, existem alguns que parecem distintos o suficiente e não são susceptíveis de serem personalizados.

HEAD para /wp-login.php conterá os seguintes para a instalação do .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_COOKIE constant, mas WP Cookie check string é codificado no núcleo, bem como set_cookie() solicita isso na origem do arquivo.

Para localizar wp-login.php , há alguns atalhos de URL (implementados em wp_redirect_admin_locations() desde o WP 3.4 (consulte o ticket # 19607 ):

/login na raiz do site faz 302 redirecionar para wp-login.php , onde quer que esteja.

Portanto, o único cenário que não pode ser detectado de forma confiável se o WP estiver instalado em e confinado ao subdiretório, sem ser usado para gerenciar a raiz do site.

    
por Rarst 07.06.2012 / 09:31
fonte
12

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

No seu exemplo de blog.stackoverflow.com , você verá:

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 simples existência de um arquivo xmlrpc.php sozinho não é segura o suficiente. Qualquer um pode dar esse nome a um arquivo.

Ressalva: O cabeçalho X-Pingback pode ser desativado, filtrando 'wp_headers' . Então, minha sugestão não é à prova de balas.

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

    
por fuxia 07.06.2012 / 09:28
fonte
6

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

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

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

Em sites que não são do WordPress, você deve obter uma resposta 200 (assumindo que a URL original sem a string de consulta forneceu 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, acabará com isso:

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" contendo a URL http://wp.me/ , 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 passagem de ?page_id=-1 na URL substitui o roteamento padrão dos segmentos de URL. Não haverá uma página com ID de -1 e, em vez disso, será exibido um redirecionamento 404 /.

    
por Nick 07.06.2012 / 11:04
fonte
3

O wp-super-cache também não está disponível em todas as instalações do wordpress, e não há nenhum formato fixo nas URLs. Embora a página de configurações permalinks forneça algumas configurações fixas para esquemas de URL que podem ser usadas, qualquer pessoa pode usar apenas um esquema de URL personalizado. Por exemplo, se alguém decide usar apenas o nome da página / postagem no URL, é mais ou menos impossível descobrir se é um site do Wordpress.

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

E, finalmente, mesmo se você fizer um get completo na URL, ainda assim não é 100% possível detectar se a página foi criada usando o wordpress. Tudo depende do modelo de tema e como ele é desenvolvido.

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

    
por Munim 07.06.2012 / 09:34
fonte
1

Duas alternativas para os comentários, defina seu próprio cabeçalho do WordPress. Solte isso nas funções do seu tema.php.

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

header('Type: WordPress');
}

O WP scan fingerprinter (ruby), ele passa por várias etapas para tentar descobrir se o WordPress está sendo usado, como procurar o diretório de plugins, nome do tema, meta tags, leia-me, etc (não tenho idéia de quão preciso isso realmente é). enlace

    
por Wyck 07.06.2012 / 17:11
fonte
0

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

    
por Mehulved 07.06.2012 / 09:45
fonte

Tags