Dois passos a seguir se você for atacado por um hack eval(base64

Para minha mais completa infelicidade, encontrei esta semana indícios de que eu — e este humilde blog —continuamos a ser vítimas de ataques de .

Mas você pode estar se perguntando como se faz para descobrir que você foi vítima de um ataque de script injection.

Bom, é fato que a maneira mais desagradável possível aconteceu comigo: Tentei acessar meu site um belo dia e descobri , informando que o site é inseguro. Daí precisei tomar uma série de medidas, entre as quais estas que estão descritas aqui, para recuperar tudo. Para que isso não aconteça com você, é importante examinar seu site periodicamente, tal como quando executamos anti-vírus em nossos computadores. Dois plugins que podem ser úteis neste caso são o Exploit Scanner e o Antivirus, sendo que confesso que prefiro o primeiro, por sua riqueza de informações. Também pode ser uma boa ideia utilizar o Sucuri Site Check, que informa a situação atual do seu site sob o ponto de vista de diversos sites especializados (há um plugin para WordPress que traz esta varredura para dentro do painel de administração, também).

Bom… se você, assim como eu, se deparar com alguma evidência de ataque, ou, no mínimo, com algum sintoma suspeito, pode seguir dois passos simples. Mas aviso que será necessário se munir de toda a paciência possível e fazer aquilo que eu acredito que seja a única opção plausível em uma situação destas: Executar alguns comandos diretamente no servidor via , para acabar com alguns comportamentos inadequados.

Se você quer uma dica de ferramenta para utilizar em uma conexão telnet (ou SSH, seu substituto mais recente e mais seguro), experimente o Putty. Para continuar a escrever este texto, assumirei que você já possui o Putty, ou outra ferramenta similar para o processo, e usarei minha própria experiência aqui no site como base.

Primeiro passo: Acabe com os arquivos world-writable

Antes de qualquer coisa, dado que fazia um boooooom tempo que eu não acessava minha conta e meus arquivos hospedados, resolvi dar uma olhada para ver se alguma de minhas pastas era, digamos, world-writable — ou seja, será que alguém do mundo exterior conseguiria alterar meus arquivos? Isto seria um enorme pecado. Para descobrir isso, já conectado ao servidor, executei a seguinte instrução:

[code lang="bash"]find . -type d -perm -o=w[/code]

E, não é que, infelizmente, encontrei ? Para evitar que pessoas do mal pudessem continuar fazendo o que bem entendessem por aqui, executei mais um comando, para que as permissões dos arquivos em questão fossem alteradas, bloqueando o acesso do mundo exterior:

[code lang="bash"]find . -type d -perm -o=w -print -exec chmod 770 {} \;[/code]

Segundo passo: Detecte quais são as infecções e as elimine

Dado que já suspeitava de que haviam arquivos vitimados com script injection, resolvi que seria importante saber quais eram os infectados. Arquivos infectados com script injection possuem linhas em seu conteúdo — geralmente no topo do arquivo, no final do arquivo, ou logo após a abertura da tag <html> — que se assemelham ao seguinte:

[code lang="php"]<!--?php /**/ //eval(base64_decode("aWYoZnVuY3Rpb25fZ....[/code]

Um comando útil para listar que arquivos são os que contém o script injection é o seguinte:

[code lang="bash"]grep -lr --include=*.php "eval(base64_decode" /caminho/do/seu/servidor[/code]

Se o output deste comando for diferente de nulo, como foi no meu caso, com mais de mil arquivos listados, pode ter certeza de que há script injection na parada. Mas não há problema, você pode se livrar desses arquivos facilmente. Basta executar um pequeno script de uma linha em perl — através da própria sessão aberta via telnet:

[code lang="perl"]for f in `find . -name "*.php"`; do perl -p -i.bak -e 's/<\?php \/\*\*\/ eval\(base64_decode\(\"[^\"]+"\)\);\?>//' $f; done[/code]

O resultado deste script será a eliminação de todas as linhas, em todos os arquivos com extensão php, do trecho de código inserido através do script injection. O processo gerará arquivos de backup como resultado — vários arquivos com a extensão bak. Isso porquê, se algo der errado e você , você ainda terá os arquivos originais a seu dispor, ainda que infectados.

Se nada se quebrar durante o processo e você não tiver mais arquivos vitimados por script injection em seu site, vale citar um comando para apagar todos os arquivos .bak, recursivamente:

[code lang="bash"]find . -type f -name "*.bak" -exec rm -f {} \;[/code]

Finalmente… uma faxina!

A etapa final, como eu a fiz, consistiu de passar um bom tempo dando uma olhada nos diretórios hospedados em cada um dos meus sites. Arquivos muito antigos foram para o beleléu — acreditem ou não, o que ocorreu no meu caso foi uma vulnerabilidade causada por um plugin de galeria de fotos esquecido há anos dentro do meu servidor — e tudo aquilo que eu julgava não saber do que se tratava, também (CUIDADO). Além disso, sempre vale dizer que é imporante resetar suas senhas. Todas. Agora.

Um ataque de script injection é aquele em que alguém, de maneira mal intencionada, se aproveita de falhas de segurança ou de vulnerabilidades em ferramentas como o WordPress para introduzir em seu código-fonte mecanismos que alterem o seu funcionamento normal. Ao visitar um site atacado, você poderia, por exemplo, ser direcionado para um endereço em que um programa mal intencionado ou vírus fosse baixado para seu computador. É por isso que estes ataques tem que ser combatidos.
Telnet é um protocolo cliente-servidor usado para permitir a comunicação entre computadores ligados em rede local, ou através da internet.
Arquivos com permissão de escrita fornecida para o mundo inteiro podem ser resultado de instalações ou desinstalações de plugins mal feitas, como foi o meu caso. Cuidado com o que instala ou deixa de instalar em seu website.
Sim, veja que estas dicas não possuem garantia alguma, e, muito menos, são garantia de 100% de eliminação dos problemas. No entanto, é verdade, vale à pena tentar.

WPTouch to the rescue

São impressionantes as coisas nas quais começamos a pensar quando nos tornamos proprietários de um smartphone. Uma delas, sem sombra de dúvidas, é o desejo de que cada site que visitamos com nosso aparelho seja preparado para os dispositivos móveis — o que, infelizmente, nem sempre é verdade. Pensando em fazer a minha parte, no entanto, foi que instalei um plugin muito interessante para o WordPress, o WPTouch.

Em resumo, o que o plugin faz é instantaneamente transformar o tema do site — sempre que este for visitado através de um iPhone, iPod touch, Android, Opera Mini, Blackberry ou similar —, de maneira que a aparência se torne a de um aplicativo desenvolvido nativamente para iPhone, contando inclusive com efeitos e carregamento em AJAX. Acabo de testar o resultado, e fiquei bastante satisfeito.

Se você por acaso me visitar munido de um desses aparelhinhos, por favor, me dê feedback.

Traga mais Readability para o seu blog

Meu amigo Rodrigo Ghedin conseguiu, sem querer, me deixar preocupado com a aparência: Não a minha, é verdade — já que neste caso nem as versões mais avançadas e recentes de Photoshop dariam jeito —, mas com a do meu blog. Tudo isso porquê, há alguns dias atrás, ele falou, em mais um de seus excelentes posts, sobre o conceito de readability.

Para quem não sabe o que readability significa, eu vou simplificar: Trata-se, basicamente, de tornar o processo de leitura mais fácil.

Ao encontrarem condições que lhes permitam ler mais facilmente, os seres humanos têm melhoradas suas capacidades de compreensão, retenção e velocidade de leitura. E para quem estiver se perguntando o que isso pode ter — ainda que de longe — a ver com os blogs que lemos no dia-a-adia, eu explico, mais uma vez. Só que desta vez vou usar um trecho do post onde o Ghedin menciona leituras realizadas na web:

(…) mesmo nas leituras mais rápidas, essenciais ao trabalho que desempenho e muito útil para ler muita coisa boa que aparece em blogs, sites e outros locais, às vezes me sinto incomodado. Não pelo monitor, mas sim pelo layout. Tem gente que publica um texto com fonte branca em fundo preto! A mim, o efeito é o mesmo que ficar meia hora olhando diretamente para uma lâmpada acesa. Meus olhos sentem essa agressão.

E esse problema de contraste é apenas um dos vários que existem. Tipografia mal escolhida, espaçamento inadequado, excesso de anúncios inseridos dentro do texto. Eu costumava pregar a máxima de que não importa aonde você escreva, o que importa, mesmo, é a mensagem. Bobagem! Já deixei de ler muita coisa boa porque a apresentação não colaborava.

Notem que um site mal cuidado, com qualquer um dos deslizes mencionados acima, pode estar prejudicando a facilidade de leitura de seus visitantes. Na prática, isso pode, inclusive, acabar se traduzindo em falta de fidelização dos leitores, ou seja: Eles podem nunca mais querer voltar ao seu site, pois se lembrarão, por exemplo, que precisaram de óculos escuros para proteger os olhos na última vez em que ali estiveram.

Felizmente, visando auxiliar a leitura de informações por milhões de internautas, um pessoal muito bacana desenvolveu um projeto — também, obviamente, chamado de Readability —, onde se encontra disponível um bookmarklet configurável para tornar qualquer página mais agradável de ler. O Rodrigo, muito oportunamente, ensina como fazer a configuração, passo-a-passo.

Com a existência de plugins prontamente disponíveis para a implantação de readability no Firefox e Google Chrome, o lado dos internautas está ainda mais garantido.

Mas acontece que eu fiquei pensando em como garantir que qualquer um que me visitasse pudesse ter acesso aos recursos de readability sem necessariamente contar com bookmarklets, extensões ou plugins. Esse conceito é tão interessante que deveria ficar ao lado de botões como os de compartilhamento de links no del.icio.us, ou de retweet, que hoje são amplamente vistos nos blogs por aí. E felizmente, não é nada complicado deixar o seu blog readability-ready.

O primeiro passo para isso é dar uma olhada no código fonte do bookmarklet que o Rodrigo ensina a configurar. No Firefox, basta clicar o botão direito sobre ele e selecionar a opção Propriedades. Você logo se deparará com algo assim no campo endereço:

[javascript] javascript:(function(){readConvertLinksToFootnotes=false;readStyle=’style-novel’;readSize=’size-medium’;readMargin=’margin-medium’;_readability_script=document.createElement(‘script’);_readability_script.type=’text/javascript’;_readability_script.src=’http://lab.arc90.com/experiments/readability/js/readability.js?x=’+(Math.random());document.documentElement.appendChild(_readability_script);_readability_css=document.createElement(‘link’);_readability_css.rel=’stylesheet’;_readability_css.href=’http://lab.arc90.com/experiments/readability/css/readability.css’;_readability_css.type=’text/css’;_readability_css.media=’all’;document.documentElement.appendChild(_readability_css);_readability_print_css=document.createElement(‘link’);_readability_print_css.rel=’stylesheet’;_readability_print_css.href=’http://lab.arc90.com/experiments/readability/css/readability-print.css’;_readability_print_css.media=’print’;_readability_print_css.type=’text/css’;document.getElementsByTagName(‘head’)[0].appendChild(_readability_print_css);})();
[/javascript]

Assustador, não é mesmo?

No entanto, não é necessário se preocupar com o que o código acima faz — que, na verdade, é somente aplicar readability à página que você está lendo. O importante é saber que é este o código que você precisará para permitir que qualquer um que visite seu site aplique readability nele. Na verdade, a coisa é tão simples que você precisará apenas criar um link em qualquer lugar da página onde escreveu um texto para que a pessoa possa clicar sobre ele. Vejamos a seguir como isso funciona no WordPress.

Acessando seu editor de temas, você precisará criar um link com o código acima no arquivo single.php — uma vez que o bookmarklet original é idealizado para transformar páginas com artigos individuais, e não sites inteiros, embora isso também possa ser feito. No meu caso, isso se traduziu da seguinte maneira:

[javascript wraplines="false"] <span class="readability">
<a title="Torne este texto mais agradável de ler!" href="javascript:(function(){readConvertLinksToFootnotes=false;readStyle=’style-novel’;readSize=’size-medium’;readMargin=’margin-medium’; _readability_script=document.createElement(‘script’);_readability_script.type=’text/javascript’;_readability_script.src=’http://lab.arc90.com/experiments/readability/js/readability.js?x=’+(Math.random());document.documentElement.appendChild(_readability_script)_readability_css=document.createElement(‘link’);_readability_css.rel=’stylesheet’; _readability_css.href=’http://lab.arc90.com/experiments/readability/css/readability.css’;_readability_css.type=’text/css’; _readability_css.media=’all’;document.documentElement.appendChild(_readability_css); _readability_print_css=document.createElement(‘link’); _readability_print_css.rel=’stylesheet’; _readability_print_css.href=’http://lab.arc90.com/experiments/readability/css/readability-print.css’; _readability_print_css.media=’print’; _readability_print_css.type=’text/css’; document.getElementsByTagName(‘head’)[0].appendChild(_readability_print_css);})();">Readability</a>
</span>
[/javascript]

O único retoque que eu fiz foi acrescentar uma classe CSS para deixar a coisa um pouco mais bonita de se ver. Não sabia exatamente qual ícone utilizar, então optei por capturar o favicon do próprio projeto Readability:

[css] .readability{
display:line;
background: transparent url(images/readability_16.png) no-repeat;
margin-left: 5px;
padding-left:26px;
padding-bottom:5px;
min-width:8px;
}
[/css]

O resultado já pode ser visto nas páginas individuais dos artigos aqui do blog. Espero, sinceramente, que desta maneira, eu esteja contribuindo para que as pessoas encontrem por aqui uma experiência de leitura um pouco mais agradável.

PS: Depois, com mais calma, pensarei em um jeito de tornar essa coisa um plugin para o WordPress.

Protegendo melhor o meu WordPress

Depois de ter sido recentemente atacado por uma script injection que surgiu do nada, fiquei mais cauteloso no que diz respeito ao blog, quando se trata de segurança.

No começo deste mês acabei encontrando um artigo da Smashing Magazine, com 10 dicas para reforçar a proteção de sites que, como o meu, utilizam o WordPress. Embora seja verdade que reforçar a segurança de um site por conta própria requeira um conhecimento mínimo de Apache — e não se sentir intimidado com alterações no arquivo .htaccess —, não há nada realmente muito cabeludo a se fazer.

Assim sendo, quero compartilhar com vocês duas das alterações que fiz:

Primeira coisa: Proteger o blog de injeções de script

Os ataques de injeção de scripts acontecem quando um hacker introduz algumas linhas de código malicioso em um site através de um de seus formulários — o de comentários, por exemplo — e então envia tais dados através deste formulário. Isso é feito, geralmente, para que se possa enganar os sistemas em uso nos sites, de maneira que eles pensem que se trata de conteúdo enviado por um usuário válido, e assim acabem permitindo, sem querer, que dados sejam acessados, editados excluídos, ou que scripts mal intencionados sejam acessados e instalem vírus nas máquinas dos internautas desavisados.

Uma das técnicas básicas para um script injection é que uma máquina cliente submeta informações que contem tags, como a tag <script>. Isso nos leva às diretivas abaixo, sugerida no artigo que li:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Ao serem adicionadas ao arquivo .htaccess, tais diretivas fazem com que qualquer requisição de acesso à uma página no blog seja verificada. Caso ela contenha referências à uma tag <script> ou, mais ainda, tenha tentado modificar o valor das variáveis GLOBALS ou _REQUEST do PHP, a requisição será bloqueada com um erro 403 (“Forbidden“) do Apache, ou seja, quem quer que esteja tentando realizar o acesso — neste caso, provavelmente alguém muito mal intencionado — será impedido de fazê-lo. Você pode até criar um documento personalizado para recepcionar alguém que tenha recebido o erro em questão:

ErrorDocument 403 /forbidden.php

Uma última palavra sobre as diretivas acima, é que estas podem ser facilmente modificadas para que incluam também as tags  <object>, <applet> e <embed>, também utilizadas em script injections. Desta maneira, reforça-se ainda mais a segurança.

Segunda coisa: Proteger o arquivo wp-config.php

Quando li o artigo da Smashing Magazine, vi que eles recomendam a proteção do arquivo wp-config.php — onde residem todas as configurações principais do WordPress, inclusive nomes de usuário e senha do banco de dados, que permitem a qualquer um com más intenções acesse todo o conteúdo do seu blog e faça com ele o que bem entender —, o que, afinal de contas, é uma excelente ideia.

O único problema é que eles, mais uma vez, se valem de alterações no arquivo .htaccess, da seguinte maneira:

<files wp-config.php>
order allow,deny
deny from all
</files>

Acredito, no entanto, que uma solução muito mais efetiva para impedir o acesso ao conteúdo do arquivo seja movê-lo para um lugar inacessível publicamente. Na prática, normalmente, isso significa movê-lo para antes da pasta public_html — onde fica tudo o que é visível para o mundo lá fora — em sua conta de usuário. Felizmente, desde a versão 2.6 do WordPress, isso é possível. Dessa maneira, basta que você utilize um programa de FTP de sua confiança e mova o arquivo em questão um nível acima.

De qualquer maneira, a dica dada pela Smashing Magazine ainda é válida se adaptarmos um pouco as coisas: Por exemplo, podemos aproveitar para proteger não o arquivo wp-config.php, mas sim o próprio arquivo .htaccess, da seguinte maneira:

<files .htaccess>
order allow,deny
deny from all
</files>

Conclusão

É óbvio que a proteção de um site contra ataques envolve uma série de outros passos e medidas de segurança, e muito mais leitura e estudo. Ainda assim, minha decisão de dividir estas duas simples alterações se deu porquê acredito serem realmente de grande valia para alguém que está pensando em proteger melhor seu conteúdo, e espero que, desta maneira, esteja prestando um serviço a quem se encontrar em uma situação difícil.

Para maiores informações, recomendo também a leitura do excelente artigo Hardening WordPress, disponível no próprio Codex da ferramenta.

Meu blog foi atacado pelo zettapetta.js

Depois de estar ausente do site por — praticamente três semanas seguidas, descobri hoje que meu site foi vítima de um ataque em massa a blogs que são movidos a WordPress. A descoberta não ocorreu instantaneamente: Tudo começou porquê, ao logar no dashboard do WordPress, percebi que a aparência das coisas estava um tanto quanto diferente, como se houvessem apagado todos os arquivos css (da área administrativa) do site. Intrigado por não entender a origem do problema — afinal, eu não havia feito grandes atualizações ou instalado novos plugins recentemente —, já havia me rendido à solução desesperada padrão, reinstalar a última versão da ferramenta.

Durante a reinstalação, graças a um vício que possuo — ficar apertando F5 freneticamente para ver todas as mensagens (temporárias) de erro que aparecem enquanto os arquivos estão sendo recolocados no lugar —, percebi que meu site estava se conectando ao domínio zettapetta.com, e logo imaginei que provavelmente havia mais caroços neste angu do que eu realmente gostaria. Um pouco de investigação me levou a descobrir que um script injection prejudicou vários sites que usam o WordPress a partir dos dias 6 e 7 de maio de 2010.

Dentre os possíveis comportamentos inadequados encontrados nos sites invadidos, identifiquei, com a ajuda de um programa de FTP, que próximo ao cabeçalho de todos os arquivos .php da minha instalação de WordPress havia um código malicioso que começava da seguinte maneira:

<?php /**/ eval(base64_decode(“aWYoZnVuY3Rpb25fZXhpc3RzKCdvYl9z.

Este era um indicador claro de que eu havia sido vítima do malware MW:MROBH:1, que se infiltra em sites como o meu e tenta instalar, nas máquinas de usuários desavisados, uma série de códigos maliciosos. Percebi que eu deveria fazer alguma coisa imediatamente.

Quando já estava me conformando com o fato de que perderia todo o conteúdo deste blog — pois as instruções iniciais de recuperação citavam medidas realmente drásticas, como excluir todos os arquivos do site —, acabei encontrando uma solução de clean up muito simples, graças ao site de segurança digital sucuri.net. Tal solução pode ser aplicada com o uso de SSH ou baixando um arquivo texto de lá — neste último caso, é necessário mudar a extensão do arquivo para .php, fazer o upload para o servidor do seu blog e executá-lo a partir de qualquer navegador. Em alguns instantes, uma mensagem similar a esta será exibida:

Tirei duas grandes lições deste episódio. A primeira, que nem sempre rodar a última versão disponível de um software te garante imunidade a algumas ameaças. A segunda, que ficar muito tempo sem visitar o próprio blog pode fazer com que estejamos executando ameaças como estas sem nem mesmo sabermos disso. Neste último caso, peço desculpas a quem quer que tenha visitado meu blog neste período de infecção, e seriamente recomendo que passem um anti-vírus atualizado em seus computadores.

Agora, voltaremos à programação normal.

Adieu, Tweetbacks: Olá, Chat Catcher!

ccbblQuem me acompanha mais de perto sabe que eu venho tentando, através de plugins para o WordPress, integrar tweetbacks ao blog. Minha insistência se baseia no fato de que, caso eu venha a escrever algo interessante ou minimamente útil, essa informação será comentada por uma ou mais pessoas através do Twitter, e eu gostaria de saber a respeito. Neste aspecto, ocorre que a integração através do plugin Tweetback realmente funciona para a maioria dos serviços de URL shortening, mas falha gravemente quando alguém faz uso do migre.me, site que é cada dia mais popular entre os usuários de microblogging brasileiros.

Tal mau funcionamento recentemente me levou há alguns dias a pedir ajuda não apenas ao desenvolvedor do plugin, mas também ao desenvolvedor do serviço brasileiro. Depois de esperar por um tempo razoável sem que houvesse qualquer resposta — fato que eu honestamente compreendo perfeitamente, pois imagino que ambos estejam tão ocupados quanto eu, com seus afazeres profissionais —, resolvi voltar à batalha, buscando qualquer alternativa que me fizesse obter um maior grau de êxito com minha vontade. Foi quando esbarrei sem querer com um artigo de Ari Herzog, especialista em mídias sociais que contribui para o site americano Mashable,  onde ele descreve a forma que ele próprio utiliza para incluir citações a seus artigos em seu blog. Trata-se de um serviço chamado Chat Catcher, criado pelo programador norte-americano Shannon Whitley e introduzido no começo deste ano em um artigo de seu blog pessoal.

O título do artigo de Ari Herzog realmente diz tudo: O Chat Catcher é mesmo mais inclusivo do que os tweetbacks, uma vez que inclui em suas buscas não apenas as citações realizadas através do Twitter, mas também aquelas que estiverem dando sopa em serviços como o FriendFeed e o Identi.ca. Basta que um artigo do seu blog apareça em um destes serviços e pronto: Uma referência a ele se tornará um trackback — ou um comentário comum, se você assim preferir, postado de volta no blog original. Entre as vantagens do Chat Catcher está o fato de que ele funciona com qualquer plataforma de blog que suporte trackbacks, e, mesmo quando isso não é possível, são oferecidas alternativas de integração scriptless. Há também um plugin para WordPress, que eu já instalei e testei aqui no blog.

Integração entre o Chat Catcher e o migre.me

Uma vez realizada a instalação, o procedimento é realmente muito simples: Na verdade, a única coisa realmente necessária é ir até as opções da página do plugin e clicar o botão Register this blog. Opcionalmente você pode listar usuários que deseja excluir das pesquisas — como o seu próprio usuário do Twitter, ou algum engraçadinho que esteja lhe mandando spam — e escolher se deseja tornar cada citação a um artigo seu um trackback ou comentário comum. Uma opção que eu não poderia deixar de mencionar é a possibilidade de moderar as citações antes que apareçam no corpo do blog.

Para concluir, é importante dizer que minha decisão final por adotar o Chat Catcher e abandonar o plugin anterior se baseia no fato de que o serviço cumpre o que promete: Lidar com qualquer serviço de URL shortening, resgatando citações custe o que custar. Neste aspecto, como ilustra a figura que se encontra neste artigo, até mesmo uma citação que eu mesmo fiz através do migre.me foi competentemente capturada. E isso, meus amigos, finalmente põe fim à esta novela.

Tentando fazer Tweetbacks e migre.me se darem bem

Até hoje eu não podia chegar a dizer que possuo um compactador de URLs favorito. De qualquer maneira, reconheço que este tipo de serviço é extremamente necessário nos tempos atuais, principalmente para qualquer um que se encontre às voltas com a arte do microblogging, sobretudo o Twitter.

Tenho acompanhado a crescente utilização, pelos blogueiros brasileiros, de um compactador de URL 100% nacional. Trata-se do migre.me, que não apenas reduz os endereços para que caibam junto às mensagens de 140 caracteres típicas dos serviços de microblogging, mas também atua como uma espécie de Digg brasileiro, computando URLs, vídeos e fotos populares no Twitter, o que eu acho simplesmente genial.

No entanto, é justamente o migre.me que vem me tirando o sono há alguns dias, tudo porquê, usuário do plugin Tweetback para WordPress como me declarei recentemente, estive às voltas com tentativas de ajustar o código PHP do autor para fazer com que eventuais citações a meus artigos através do serviço brasileiro também aparecessem por aqui, entre os últimos comentários.

Minha batalha começou quando, recentemente, percebi que o migre.me já possui uma API. É verdade que dá um pouco mais de trabalho mexer com ela pra obter as URLs compactadas, já que é preciso ler um arquivo XML para que a mágica aconteça, mas nada de outro mundo.

No arquivo principal do plugin para WordPress que eu estou usando para exibir os Tweetbacks aqui no blog — tweetback.php — há uma função chamada fh_tweetback_getshorturl, que é, como o nome diz, responsável por obter as URLs compactadas de serviços como o tinyurl, bit.ly e outros. Foi lá onde eu acrescentei algumas coisas por conta própria para fazer com que também as URLs compactadas pelo migre.me fossem levadas em conta na hora de verificar se houve citações do Twitter por aqui.

A função em si ficou assim — notem que todos os comentários em inglês do autor do plugin foram mantidos… eu só acrescentei mesmo a parte do migre.me:

  function fh_tweetback_getshorturl($permalink,$provider='tinyurl.com') {
  $permalink = urlencode($permalink);
  //http://blog.cli.gs/news/analysis-of-linking-patterns-on-twitter-cligs-scores-well
  switch($provider) {
  case 'tinyurl.com':
  return fh_tweetback_curl('http://tinyurl.com/api-create.php?url='.$permalink);
  case 'is.gd':
  return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
  case 'bit.ly':
  return fh_tweetback_curl('http://bit.ly/api?url='.$permalink);
  case 'twiturl.de':
  return fh_tweetback_curl('http://api.twiturl.de/friends.php?output=txt&new_url='.$permalink);
  case 'migre.me':
  $xml = simplexml_load_file('http://migre.me/api.xml?url='.$permalink);
  return (string)$xml->migre;
  /* blearg, I really dont feel like all that signupapikeystuffpostcomplicated, what the hell.
  * Maybe I'll have more motivation later on to register or do post mechanism, for now on
  * its just like that. tinyurl ftw! :) 
  * (and yes, I understand why registration and keys can make sense. however, I am still too lazy for that.)
  case 'twurl.nl':
  return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
  case 'snipurl.com':
  return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
  case 'snurl.com':
  return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);*/
  default:
  return false;
  }
  return false;
  }

Pois bem: Devo dizer que, antes de partir para a alteração do código do plugin, fiz um teste em arquivo PHP separado para verificar se a obtenção de URLs aqui do blog compactadas pelo migre.me estava funcional, inclusive levando em conta que elas devem ser tratadas pela função PHP urlencode.

Os testes funcionaram perfeitamente. Uma maravilha, mesmo. No entanto, depois de começar a postar uma série de testes a partir do TweetDeck, percebi que os tweetbacks ora aparecem, ora não aparecem no blog. E, sinceramente, estou numa dúvida violenta entre se tratar de um problema no plugin, ou algo que eu esteja fazendo errado com a própria API do migre.me.

A impressão que tenho é que eu quase cheguei lá, mas alguma coisa ainda parece precisar de ajustes. Como entendo um pouquinho de PHP mas no momento estou mais pra weekend programmer do que qualquer outra coisa, enviei o link deste texto para o desenvolvedor do migre.me, na esperança de que ele possa me apontar algum problema — caso aplicável. Também enviei um e-mail ao desenvolvedor do plugin Tweetback, Florian Holzhauer, asking for his advice:

Hi there, Florian!

My name is Daniel Santos, and I’m a Brazilian WordPress user. I came across your e-mail address thanks to your excellent Tweetback plugin for WordPress, which not only I’ve been using in my own blog, but also have been trying to extend.

Let me explain: A lot of Brazilian users have been exchanging abroad URL shorteners like http://tinyurl.com or http://bit.ly for http://migre.me, which is a 100% Brazilian-made URL shortener. Developers from http://migre.me have recently deployed an XML-based API (http://migre.me/blog/api-gerador-de-urls/) that can be used to retrieve shortened URLs to be used as one best fits.

After implementing some code using your PHP plugin file as a reference, I created a variation of it (which I’m sending you, attached to this message). Simple enough, I have added some lines of code to your fh_tweetback_getshorturl function, retrieving a XML file and getting one attibute out of it. Besides, I added http://migre.me to the Admin Panel backend, exactly as I noticed you yourself did with the other services your plugin works with.

Unfortunately, there IS a problem, as shortened URLs created by http://migre.me sometimes appear listed in my post’s comments, sometimes not. Fact is, I don’t know, out of three possible situations, which is actually happening:

(1) my changes to your code were not enough — or are possibly wrong;
(2) the problem might be located in my misuse of http://migre.me API itself.
(3) my PHP skill sucks (LOL)

As #3 is currently impossible to solve and I have contacted http://migre.me developers for help, I’m asking you to please help me figure out if the problem could be with the plugin itself.

Hoping that you will answer me as soon as possible, I would like to thank you in advance, and possibly expect my contribution to your plugin to be useful – as I think several Brazilian tweetbackers will find.

Best regards,

Daniel Santos

http://danielsantos.org/

No entanto, este meu artigo é também um pedido de ajuda pra quem mais quiser se habilitar a fazer a coisa funcionar. Uma vez que a popularidade do migre.me aumenta cada dia mais entre os internautas e blogueiros brazucas, penso que a integração com o plugin para WordPress seja uma ótima pedida.

Ah, é claro: A minha modificação do plugin pode ser visualizada através deste link.

Aderindo aos Tweetbacks

Qualquer um que já tenha escrito pelo menos meia dúzia de artigos em um blog sabe o que é  — ou, pelo menos, já ouviu falar de — um linkback: Também popularmente conhecido como pingback ou trackback, trata-se de um mecanismo que notifica um autor, em seu próprio blog, todas as vezes em que outras pessoas fazem menção a um ou mais artigos seus em outro endereço da Grande Rede de Computadores.

Exemplos de tweetback por aqui

Exemplos de tweetback por aqui

Pois bem: Depois de haver recentemente instalado e saudado com entusiasmo o TweetDeck, me dei conta de alguns links interessantes que mencionavam alguns artigos que eu havia escrito por aqui recentemente. Minha conclusão óbvia é de que, assim como alguns blogueiros têm evoluído para formas aleatórias de microblogging, as pessoas têm usado também seus serviços de microblogging — sobretudo o Twitter como forma de linkback. Esse novo tipo de link, chamado tweetback, foi na verdade introduzido no começo deste ano por Rachel Cunliffe, em seu post  10 Ways Twitter Will Change Blog Design in 2009, publicado no site Mashable:

Bloggers will start to add “Tweetbacks” to their blog posts. The simplest version will show the number of people who have tweeted this post (including all reverse engineered tinyurls). Tweetbacks are not yet available.

Options will include:

  • Showing what tweeters are saying about the post
  • Replies to those tweets from others
  • Showing who is tweeting the post
  • Showing the tweeters’ avatars
  • Ordering tweeters by Twitter influence
  • Mixing tweets in with comments, rather than displaying them separately

Imaginei logo que eu deveria aderir a algum tipo de integração dos assim chamados tweetbacks com o meu próprio blog: Minha motivação foi realmente o fato de acreditar que as pessoas efetivamente têm passado menos tempo visitando e comentando posts dos blogs, e que têm dado preferência ao Twitter, para tanto. Depois de procurar um pouco por aí, acabei fazendo algumas experiências e me decidi com relação ao plugin Tweetback, escrito por Florian Holzhauer.

De maneira resumida, ele é capaz de varrer o Twitter em busca de links que apontem para os artigos do blog, mesmo que eles estejam ocultos por serviços de URL shortening — atualmente, aliás, são suportados, além do tinyurlpadrão —,  o is.gd e o bit.ly, sendo que o autor já prometeu suportes adicionais em breve. Uma vez encontrados estes links, eles são transformados em tweetbacks, e publicados no blog acompanhados dos avatares de seus autores, no Twitter.

Opções do plugin

Opções do plugin

Para não dizer que a instalação foi totalmente plug and play, a única coisa que resolvi fazer foi uma edição no arquivo PHP fonte, apenas para aumentar o tamanho do avatar padrão, para que ele coincidisse com o tamanho que venho usando no blog.

Seja como for, o importante é saber que qualquer comentário ou reação aos meus artigos que venha via Twitter agora passará a ser capturados por aqui — figurando na barra lateral, junto aos comentários feitos direto no blog —-, o que me permitirá ter uma idéia melhor das reações com relação ao que eu escrevo. Espero ter boas surpresas… :)

Finalmente um TinyMCE ligeiro no meu WordPress 2.7

Desde o começo de dezembro do ano passado eu vinha enfrentando severos problemas ao tentar digitar meus artigos para publicação aqui no blog: Carregar o TinyMCE, editor WYSIWYG padrão que acompanha o WordPress, levava mais de 10 segundos na raposa de fogo, e, em seguida, digitar cada mera letra parecia uma tortura interminável, só perdendo para o tempo gasto ao ter que apagar alguma coisa usando o backspace ou formatando os textos.

Tentei, antes de qualquer coisa, usar uma versão recente do Opera para acessar o painel de edição de artigos, o que funcionou maravilhosamente bem, já que a lentidão desapareceu por completo na digitação. No entanto, não dava pra ficar usando um navegador diferente só pra criar artigos no blog e, assim sendo, cogitei a possibilidade de que pudesse se tratar de um problema qualquer com uma das inúmeras extensões que eu possuo instaladas no Firefox.

Infelizmente, após desabilitar todos os plugins e realizar um fresh setup, o problema não se resolveu: Cada caracter ainda levava uma eternidade para aparecer na tela ao digitá-lo. O próximo suspeito da minha lista foi o próprio WordPress. Pensei se tratar de algum bug da nova versão do WordPress, já que, afobado por testar novas funcionalidades, naquele momento eu vinha usando algumas versões beta.

Quando a versão 2.7 saiu oficialmente e eu reparei que o problema de lentidão ainda não dava o braço a torcer, comecei uma busca um pouco mais dedicada atrás de uma solução. Se na primeira quinzena de 2009 fiquei sem publicar uma palavra que fosse por aqui, foi por conta de estar ocupado atrás de cada pequena referência que pudesse representar uma luz no final do túnel.

No começo dessa semana encontrei essa luz, lendo um artigo do Andrew Ozz, chamado Troubleshooting TinyMCE in WordPress 2.7. Nele, Andrew lista alguns pontos que podem ser tentados por qualquer pessoa se seu editor resolve não aparecer ou funcionar corretamente. Alguns pontos eu já havia tentado, mas foi no sexto que eu parei, pois, recentemente havia encontrado diversos erros provenientes da página em que o TinyMCE é carregado no WordPress, examinando-a pelo console de errors do Firefox:

Delete both wp-admin and wp-includes directories and upload fresh copies from the WordPress installation package.

Precisei esperar até o final da semana para ter tempo de ver se a coisa funcionava, mas valeu cada segundo de espera: Eis que abri meu programa de FTP favorito e mandei bala na orientação. Após alguns minutos de upload, BINGO! O editor estava novamente lépido e veloz.

Ah, é claro, a explicação: Ao renovar sobretudo o conteúdo da pasta wp-includes, pude me certificar de que os diversos arquivos em javascript ali existentes estivessem em sua versão mais recente: Após o procedimento, não houve qualquer problema no console de erros da raposa, o que me fez pensar que alguma falha acidental deve ter ocorrido entre a migração da última versão beta do 2.7 para a oficial. Mea culpa.

Plainscape: Para começar 2009 bem

Precisava — como já precisei em outras vezes — de uma mudança de ares por aqui para dizer que poderia começar bem 2009 (ainda que começando a escrever 16 dias depois da virada do ano). Para isso, depois de muito procurar, acabei encontrando um tema que achei bacana, o Plainscape.

Para meus padrões atuais de gosto, o tema é genial: Totalmente clean, o que o torna sofisticado. Conta com uma barra lateral direita — ao contrário do Apricot, tema que eu vinha usando até então, onde as coisas são agrupadas na esquerda. Além disso, já possui suporte nativo ao novo — e, por mim, mais do que amplamente antecipado — recurso de comentários endentados (ou threaded comments) da versão 2.7 do WordPress.

Espero que o novo tema agrade, e que me inspire a escrever um pouco mais por aqui.