Como já era de se esperar, o Facebook vem fazendo o possível e o impossível para bloquear quaisquer meios de exportar os contatos. Já bloqueou extensões e plugins que faziam isso. Tudo para dificultar o crescimento do Google+. Ok, dá pra entender, vai contra o que é útil para o usuário, mas vai a favor dos interesses do Facebook.

Aqui vai a dica então… tudo que você vai precisar para isso é uma conta de email no Yahoo! Caso não tenha, dá pra criar uma rápido e sem custo.

Passo a passo

1. Abra a página do Yahoo! em http://www.yahoo.com.br/

2. Clique em “email”, no menu lateral esquerdo, para acessar o seu email @yahoo.

3. Entre com seu handle Yahoo! e sua senha, e clique no botão para entrar.

4. No menu superior do webmail, clique em “Contatos”

5. No lado direito da tela que vai abrir, siga com a primeira opção, “Importar contatos”

6. Escolha Facebook, e autorize o acesso na janela que vai abrir.

7. Com isso, o Yahoo! vai fazer a importação de todos os seus contatos do Facebook.

8. Clique no link para ver a lista dos contatos que acabaram de ser importados.

9. Marque todos eles, vá no botão “Ações” logo em cima, e escolha “Exportar tudo”.

10. Clique para exportar os contatos no formato Yahoo! CSV, e os contatos já estarão prontos para serem importados no Google, ou abertos em uma planilha.

11. Pronto! Só se logar no Gmail, e importar o arquivo que você fez download na parte de contatos. Entrando no Google+, todos estarão lá, prontos para serem convidados / adicionados.

É bom fazer isso o quanto antes… vai saber quanto tempo vai demorar até o Facebook bloquear isso tambem.

Artigos relacionados

• Nenhum artigo relacionado

A forma mais comum de fazer isso, é usando o serviço cron (em ambientes Unix), ou o agendador de tarefas (no Windows). Embora ambos funcionem bem, existe uma alternativa, que é usar o próprio WordPress para isso.

Como fazer

Para agendar uma tarefa, existe uma função chamada wp_schedule_event(). Uma chamada típica dessa função seria da seguinte forma:

<?php
wp_schedule_event(time(), 'hourly', 'hook');
add_action('hook', 'funcao_agendada');
?>

Isso agendaria a função “funcao_agendada()” para ser executada de hora em hora, na hora atual.

O primeiro parâmetro informa a hora de agendamento. Como passamos time(), que se traduz na hora atual, o WordPress usará esse valor como hora. O segundo parâmetro é a frequência, que pode ser hourly, daily ou twicedaily (respectivamente de hora em hora, diariamente, ou duas vezes por dia). E por último, o nome de uma “action”, que indicará a função a ser executada.

Para remover o agendamento, a chamada é feita a wp_clear_schedule_hook(), passando como parâmetro somente o nome do hook utilizado (no caso, “hook”).

Um detalhe é que essa função deve ser chamada uma única vez, por isso, pode ser conveniente colocá-la dentro de um plugin, e executar o agendamento na ativação, e remover o agendamento na desativação.

Uma outra forma de se agendar, sem usar plugins, é usar a função wp_next_scheduled() para checar se o evento já foi agendado, da seguinte forma:

<?php
add_action('meu_evento', 'funcao');
function ativacao() {
    if (!wp_next_scheduled('meu_evento')) {
        wp_schedule_event(time(), 'hourly', 'meu_evento');
    }
}
 
add_action('wp', 'ativacao');
 
function funcao() {
    // isso executará de hora em hora
}
?>

Assim, caso o evento não esteja agendado, o WordPress se encarregará de agendá-lo.

As vantagens

A principal vantagem é que o agendamento fica independente de qualquer coisa externa. Tudo fica gerenciado pelo próprio WordPress, e numa eventual mudança de servidor, não haveria necessidade de se preocupar com as tarefas agendadas.

As desvantagens

Como não temos um daemon pra verificar a hora, e chamar as tarefas, dependemos de um visitante (humano ou não) pra executar as tarefas. Em cada acesso ao site, o WordPress checa se existe alguma tarefa que já deveria ter sido executada. Caso exista, ele executa. Simples assim.

Um problema nisso é que não há garantia de que a tarefa será executada precisamente no horário agendado, mas sim, no primeiro acesso após esse horário (que pode ser segundos, num site muito visitado, ou minutos/horas em um site com quase nenhum acesso).Caso a rotina que se queira agendar seja sensível a hora, é melhor usar os métodos convencionais.

Conclusão

Usar a funcionalidade de agendamento do WordPress pode ser uma boa alternativa, principalmente quando não há preocupação com o “quando” a tarefa será executada, ou quando não se tem acesso aos sistemas de agendamento do servidor, o que pode ser comum em ambientes compartilhados.

Artigos relacionados

• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

<meta name="generator" content="WordPress 2.8.4" />

Muita gente não gosta de anunciar para o mundo a versão usada. Seja por não querer exibir o uso do WordPress, ou por medo de alguem usar essa informação para um possível ataque contra essa versão específica do WordPress, existe uma forma muito simples de retirar isso do cabeçalho, sem precisar editar os arquivos do sistema (que a priori, nunca devem ser editados).
Essa tag é inserida no cabeçalho através de uma action padrão, chamada wp_generator. Para não exibir, basta remover a action, adicionando o seguinte código no functions.php do seu tema:

<?php
remove_action('wp_head', 'wp_generator');
?>

Pronto, com isso o seu site não irá mais exibir esta tag no cabeçalho.

Artigos relacionados

• Agendando eventos no WordPress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

IPs usados no envio

Tente fazer os seus envios usando poucos endereços IPs, e que sejam consistentes. Se os seus emails estão saindo de vários IPs de redes diferentes, os servidores de destino podem achar que seu sistema está falsificando os IPs de envio, ou usando alguma rede para fazer o envio (botnets, por exemplo). Com isso, sua chance de ter o email marcado como spam aumenta bastante.
Se você se limita a fazer o envio a partir de um único IP, ou poucos IPs, não vai sofrer com esse tipo de problema. Além disso, os provedores agora trabalham com o conceito de “reputação” de um IP. Ou seja, se você envia emails consistentemente através de um IP, e esses emails tem taxa de reclamação baixa, a tendência é que a reputação suba.

DNS reverso

O sistema de DNS serve para traduzir nomes para IPs. Por exemplo, quando digita “www.ataraxia.com.br” no seu navegador, ele é traduzido para um endereço IP (no momento em que escrevo, 75.119.213.142). Hoje em dia, o DNS é essencial para o funcionamento da Internet.
Assim como existe a tradução de nomes para IPs, tambem existe a tradução inversa, ou seja, de IPs para nomes. E é importantíssimo que o endereço IP do seu servidor de email possa ser traduzido de volta para o nome dele.
Servidores que não tem DNS reverso cadastrado e apontando de volta para ele mesmo normalmente não conseguem mandar email de forma consistente, pois a maior parte dos filtros já barra a conexão antes mesmo de receber a mensagem. Ou seja, o conteúdo nem mesmo é analisado.

Use um remetente consistente

O remetente é o nome e email que aparecem para quem recebe o email. Tente usar o mesmo para a campanha inteira. Colocar nomes e emails diferentes para cada email que sai é mais um indício de spam, pois spammers falsificam essas informações para tentar ocultar sua identidade. Coloque no remetente algo que deixe bem claro quem você é.

Publique registros SPF

O SPF é um framework que utiliza registros DNS para divulgar informações sobre permissão de envio de emails, e tem a intenção de combater o envio de emails falsificados.
Um registro SPF indica para o mundo quem tem permissão de mandar emails usando um domínio. E como quem tem controle sobre um domínio e seus registros é normalmente a organização detentora da marca, seria uma forma da organização dizer: “somente os servidores X, Y e Z podem mandar email usando minha marca”.
Todos os grandes provedores checam registros SPF, e um email que falhe nessa checagem já é mais um indicativo de possível falsificação de email.
Não vou colocar um tutorial sobre SPF nesse artigo, pois foge um pouco do escopo, mas para saber mais sobre a tecnologia, e como implementar, basta visitar o site http://www.openspf.org/. Existe tambem um ótimo assistente para geração do registro SPF para publicação no servidor DNS.

Assinaturas DomainKeys e DKIM

DomainKeys é uma tecnologia que usa criptografia para verificar o domínio de quem enviou a mensagem, e a integridade das mensagens. É usada principalmente pelo Yahoo!, e foi usada como base pelo IETF para o desenvolvimento do DKIM (DomainKeys Identified Mail), sucessor do DomainKeys.
A idéia é usar duas chaves, uma pública e uma privada. A chave privada fica guardada no servidor que faz o envio, e cada email é assinado digitalmente usando essa chave privada. A chave pública é disponibilizada via DNS, e qualquer um que receba um email assinado usando a DomainKeys e/ou DKIM pode verificar se a mensagem foi realmente enviada por um servidor autorizado, checando a assinatura através da chave pública.
Além disso, a assinatura garante também que a mensagem não foi modificada em trânsito, pois caso tenha sido modificada, a assinatura não vai conferir.
Embora o DKIM tenha vindo para ser o sucessor do DomainKeys, a maior parte dos grandes provedores checam as duas assinaturas, então não existe problema em assinar a mensagem duas vezes, pois ambas coexistem sem problema.

Lista de emails

Qualquer email que esteja na sua lista deve ter dado a permissão explícita para que você faça o envio de emails. Qualquer inscrição deve preferencialmente utilizar o mecanismo de “double opt-in”, ou seja, a pessoa coloca seu email em um formulário no seu site, você envia um email de confirmação com um link, e só adiciona a pessoa na sua lista após essa confirmação. Isso evita a adição de pessoas que não pediram para ser cadastradas, e com isso, evita reclamações.

Manutenção da lista

A regra número 1 é bem simples: respeite seus usuários. Se alguem não quer mais receber seus emails, não envie mais. Vai ser um usuário a menos gerando reclamações. Não vale a pena forçar seus emails goela abaixo dos usuários.
Todo email que você enviar deve conter um link para que o usuário possa sair da lista. Esse link deve funcionar, de preferência de forma automática e imediata.
Além disso, qualquer email que gere um “bounce” deve ser removido da lista, caso seja um erro permanente (por exemplo, “email inexistente”). Erros não permanentes (por exemplo, “caixa postal cheia”) devem ser removidos caso persistam por alguns envios.

Formato do email

Todas as mensagens devem seguir o padrão descrito na RFC 5322. Esse padrão é o sucessor da RFC 2822, que por sua vez é o sucessor da RFC 822. Esse padrão descreve o formato que um email deve seguir.
Caso envie emails em HTML, siga os padrões descritos pelo W3C.
Adicione sempre o cabeçalho “Precedence: bulk”, para sinalizar ao servidor de destino de que seu email faz parte de um envio em massa. Isso ajuda o servidor que recebe a priorizar melhor a entrega das mensagens, caso esteja sobrecarregado.
O assunto do email deve ser relevante, e ter relação com o conteúdo da mensagem.

O email em si

Evite uso de palavras chaves normalmente associadas a spam. Evite o uso de pontuação em excesso, como por exemplo, muitas exclamações.
Caso esteja enviando email em HTML, não esqueça de fazer tambem uma versão em texto puro, para quem não lê HTML. Por exemplo, muitos dispositivos móveis não lêem emails em HTML. Além disso, emails somente em HTML muitas vezes ganham uma pontuação nos sistemas antispam.
No HTML, evite colocar somente imagens. Tente manter uma boa proporção de texto para imagem. Siga os padrões da W3C, colocando o atributo “alt” nas imagens. Além disso, lembre-se que por padrão, os grandes provedores não exibem imagens externas por padrão, então caso seu email contenha somente imagens, existe uma boa probabilidade do email não ser lido.

Blacklists e whitelists

Tente fazer monitoramento constante nas várias listas negras existentes na Internet. Caso seu servidor seja listado, começará a ter problemas de entrega, pois qualquer servidor configurado para checar a lista negra irá barrar sua conexão. Tente trabalhar de forma a evitar a entrada nessas listas, e caso entre, tente corrigir o problema e providenciar a saída o mais rápido possível.
Assim como existem as listas negras, existem tambem listas brancas, de servidores que foram cuidadosamente verificados, e que fazem envio de email de forma responsável. A mais famosa é a certificação SenderScore da ReturnPath. Existe um custo, mas por sua vez, uma vez certificado, basta manter as boas práticas para conseguir melhores taxas de entrega para grandes provedores, como Hotmail e Yahoo!.

Conclusão

Resumindo: mandar emails para a Internet de forma consistente é um verdadeiro inferno hoje em dia. E acredite, você certamente terá problema de entregas uma hora ou outra. Não tem muito pra onde fugir. Mas seguindo essas regras (simples?), dá pra se manter o nível de rejeição em um patamar aceitável.
Alguem tem alguma dica extra? Postem nos comentários!

Artigos relacionados

• Evitando spam em formulários
• Evitando fornecer seu email verdadeiro
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Acessando sites fora do ar
• Envio de emails em PHP
• Segurança no envio de emails em PHP

CFLAGS="-O2 -fomit-frame-pointer -march=nocona -pipe"

Essas flags especificam uma otimização nível 2 (pode ir de 0 a 3 – o 3 quebra alguns pacotes, por isso é recomendável usar o 2), e especifica também para qual conjunto de instruções os binários serão gerados. No meu caso, estou dizendo que os binários deverão ser compilados para se usar todo o poder do processador nocona (os dual/quad cores da Intel).
Até aí, tudo funcionando bem. Montei um sistema todo com essas flags, e estava tudo muito bem, até que precisei instalar o Bacula, um software para se fazer backups de sistemas completos.
O Bacula, com as CFLAGS padrões estava gerando um binário quebrado. Pesquisando, descobri que o projeto Hardened do Gentoo, que usa uma série de artifícios para gerar executáveis mais seguros e imunes contra ataques como buffer overflow era o responsável, pois por padrão ele passa a flag “FORTIFY_SOURCE” para o compilador, e isso estava quebrando o Bacula.
Uma das formas de se resolver esse problema seria alterando as CFLAGS no /etc/make.conf, adicionando -U_FORTIFY_SOURCE a elas. Porém, o grande problema é que as CFLAGS são válidas globalmente, e dessa forma, todos os pacotes seriam compilados com essa flag extra, matando parte dos recursos do projeto Hardened.
O que eu queria era poder compilar somente o Bacula com essa flag extra. Uma das formas é usar o diretório /etc/portage/env para criar variáveis de ambientes específicas para cada pacote.
Basta seguir os seguintes passos:

1. 1. Pegue o nome completo do pacote, na forma categoria/pacote. No caso do Bacula, o nome completo é app-backup/bacula.
2. 2. Crie o arquivo /etc/portage/env/categoria/pacote, ou no nosso caso, /etc/portage/env/app-backup/bacula. Caso o diretório “env” não exista, crie toda a árvore necessária.
3. 3. Nesse arquivo, você pode especificar as variáveis de ambiente que serão definidas exclusivamente para a compilação do pacote. Assim, podemos definir CFLAGS neste arquivo:

   CFLAGS="${CFLAGS} -U_FORTIFY_SOURCE"

Pronto. Com isso, temos a flag extra -U_FORTIFY_SOURCE adicionada às flags globais, e só serão utilizadas para o pacote em questão.

Artigos relacionados

• O limite de 4 (ou 3?) Gb de memória

Criando um plugin

Neste artigo, vamos mostrar o passo a passo da criação de um plugin simples, que visa guardar em uma tabela o número de visualizações de cada post do blog. Só isso. Não teremos gráficos, tabelas, nada do tipo. Apenas vamos guardar os dados, que podem ser utilizados por uma outra ferramenta qualquer.
O objetivo não é apenas mostrar como se criar um plugin. A partir deste esqueleto, adicionar mais funcionalidades fica mais fácil.

O cabeçalho do plugin

Antes de mais nada, logo no início precisamos ter um cabeçalho no arquivo do plugin que informará ao WordPress algumas informações, como nome do plugin, uma descrição, autor, versão, e outras coisas. É importante ter isso bem definido.
Essas informações entram em um comentário logo no início do arquivo. No nosso caso, teremos o seguinte:

<?php
/*
Plugin Name: View Counter
Description: Increments a counter each time a post is viewed
Version: 1.0
Author: Bruno Lustosa
Author URI: http://www.ataraxia.com.br/
*/

Pronto, já temos aí o nome do plugin (View Counter), uma breve descrição do que ele faz, a versão, o nome do autor e a URL do autor, para referência. O WordPress exibe essas informações na página dos plugins na área administrativa. Coloquei as informações em inglês, pois a interface administrativa deste blog está toda em inglês.

Os hooks

Entenda os hooks como ações onde você pode criar um callback. Ou seja, sempre que determinada ação for executada no WordPress, uma função definida por você será chamada. No nosso caso, vou definir 2 hooks e uma ação (a ação é parecida com o hook, mostrarei a diferença logo abaixo).

// Hooks
register_activation_hook(__FILE__, "viewcounter_activate");
register_deactivation_hook(__FILE__, "viewcounter_deactivate");
add_action('save_post', 'viewcounter_insert');

O primeiro hook determina que a função viewcounter_activate() será executada quando o plugin for ativado. Esta função cuidará da criação da tabela, caso necessário. Da mesma forma, o segundo hook executará viewcounter_deactivate(), que destruirá nossa tabela, para deixar o sistema limpo como estava antes da ativação. É sempre uma boa prática remover o que criamos após a desinstalação.
A ação é bem semelhante ao hook, e no caso, executará a função viewcounter_insert() assim que um post for salvo. Esta função irá inserir uma linha em nossa tabela, definindo o número de leituras como sendo zero.

Nossa tabela

Iremos criar uma tabela bem simples para guardar as nossas informações. Tudo que precisaremos, é de um campo para guardar o ID do post, e outro pra guardar o número de visualizações. Sim, poderíamos alterar a tabela de posts e adicionar um campo com o número de visualizações, porém, prefiro não mexer em tabelas do sistema, para evitar problemas de compatibilidade futura (vai que uma versão futura do WordPress possui um campo com esse mesmo nome?).
O comando para a criação da tabela:

CREATE TABLE viewcounter (
    post_ID INT NOT NULL PRIMARY KEY,
    views INT NOT NULL DEFAULT 0
);

O hook de ativação

Com a definição da nossa tabela em mãos, vamos partir para a função de ativação do plugin. Ela será executada uma única vez, quando o administrador ativar o plugin.
Nossa função, por segurança, irá checar se a tabela que queremos criar já existe, para evitar erros. A checagem usará o comando SQL SHOW TABLES.
A função ficará assim:

function viewcounter_activate() {
 
    global $wpdb, $viewcounter_table;
 
    if ($wpdb->get_var("SHOW TABLES LIKE '{$viewcounter_table}'") != $viewcounter_table):
        $wpdb->query("CREATE TABLE {$viewcounter_table} (post_ID INT NOT NULL PRIMARY KEY, views INT NOT NULL DEFAULT 0)");
    endif;
 
} // viewcounter_activate

Note que temos duas variáveis globais. A primeira, $wpdb, é do próprio WordPress, e é usada para acessar o banco de dados e executar queries. A segunda, foi definida por nós, e contem o nome da tabela que usaremos. Lembra, que durante a instalação do WordPress, ele te pediu um prefixo para as tabelas? Ao invés de deixarmos um nome fixo, é sempre bom definir o nome da tabela usando este prefixo.
Assim, esta segunda variável global foi definida fora da função, da seguinte forma:

global $viewcounter_table;
$viewcounter_table = "{$wpdb->prefix}viewcounter";

Resumindo, se você definiu o prefixo para as tabelas do WordPress como wp_, então nossa tabela se chamará wp_viewcounter. Isso é especialmente importante caso seu plugin seja usado em um sistema multi-usuário, como o WordPress MU.

A desativação

Bem semelhante à nossa função de ativação, temos a função que será executada quando o plugin for desativado. A idéia aqui é limpar tudo que fizemos, deixando o sistema como estava antes. Para tanto, basta destruir a nossa tabela.

function viewcounter_deactivate() {
 
    global $wpdb, $viewcounter_table;
 
    $wpdb->query("DROP TABLE {$viewcounter_table}");
 
} // viewcounter_deactivate

Simples assim. Desativou o plugin, destruiu a tabela.

Quando salvamos o post

Assim que um post é salvo, temos a função viewcounter_insert() que será chamada, tendo como parâmetro o ID do novo post. Esta função deve inserir uma linha em nossa tabela, indicando que esse novo post teve 0 visualizações até o momento, o que é lógico, pois ele acabou de ser criado.
A função também fica bem simples:

function viewcounter_insert($post_ID) {
 
    global $wpdb, $viewcounter_table;
 
    $wpdb->query("INSERT INTO {$viewcounter_table} (post_ID, views) VALUES ({$post_ID}, 0)");
 
} // viewcounter_insert

A contagem propriamente dita

E por último, temos a contagem das visualizações. Para tanto, teremos uma função chamada viewcounter_update(), que receberá como parâmetro o ID do post a ser atualizado. Para conveniência, essa função também irá retornar o número atualizado de visualizações que o post teve, que poderá ser usado no template em algum lugar.
Esta função tem algumas checagens extras que são feitas por segurança. Por exemplo, caso um post antigo seja visualizado, precisaremos rodar a função que cria a linha para o post, pois como ele foi criado antes da ativação do plugin, o hook anterior não foi chamado.
A função pode ficar assim:

function viewcounter_update($post_ID) {
 
    global $wpdb, $viewcounter_table;
 
    if (is_null($wpdb->get_var("SELECT views FROM {$viewcounter_table} WHERE post_ID = {$post_ID}"))):
        viewcounter_insert($post_ID);
    endif;
    $wpdb->query("UPDATE {$viewcounter_table} SET views = views + 1 WHERE post_ID = {$post_ID}");
 
    return $wpdb->get_var("SELECT views FROM {$viewcounter_table} WHERE post_ID = {$post_ID}");
 
} // viewcounter_update

A primeira query checa se o retorno é vazio, e caso seja, chama a função viewcounter_insert() para inserir uma linha com 0 visualizações. Em seguida, executa um update incrementando em 1 o número de visualizações. E por último, retorna o número atual de visualizações do post.

Atualizando

Tudo que faltou agora, é indicar o ponto onde viewcounter_update() deve ser chamada. Na hierarquia dos templates, o ponto ideal para colocarmos nossa chamada é no arquivo single.php.
Bastaria uma simples chamada como:

<?php
$num = viewcounter_update($post->ID);
?>

E já teríamos o banco atualizado (claro, supondo que temos em $post o objeto com o post). Caso queiramos exibir o número atual de visualizações, podemos utilizar a variável $num em qualquer ponto do template para mostrar ao usuário quantas vezes aquele post foi visto.

Conclusão

Este foi apenas um exemplo, bem tosco, de como criar um template para o WordPress. É claro que ele pode ser melhorado, e muito. Inclusive, aceito sugestões nos comentários.
Estou disponibilizando um arquivo com este plugin, para quem quiser baixar e experimentar.

Artigos relacionados

• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado

Para diferenciar, eu poderia usar URLs como as abaixo:

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado?rss

http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado?email

Desta forma, o site tem como saber de onde o visitante veio, bastando colocar no feed o sufixo “?rss”, e nos boletins o “?email”. O site checaria se a URL contém um desses sufixos, e incrementaria um contador em algum lugar (banco de dados, arquivo, etc).
O grande problema, é que uma vez que os buscadores encontrem essas URLs alternativas, irão notar que o conteúdo é o mesmo para as 3 páginas, e existe a chance de que seu site seja penalizado por isso.
Uma das formas de se lidar com isso é usar a tag <link> para informar qual é a URL “canônica” da página atual. A tag é simples:

<link rel="canonical" href="http://www.example.org/caminho-da-pagina" />

Esta tag é a mesma nas 3 páginas, e indica ao buscador qual é a URL canônica da página. Seguindo o nosso exemplo, nas 3 páginas acima, teríamos a tag:

<link rel="canonical" href="http://www.ataraxia.com.br/posts/evitando-conteudo-duplicado" />

Claro, esta tag serve como uma “dica” para os buscadores, e eles podem usá-la ou não. Na maioria das vezes, ela será usada.
E embora eu tenha dado o exemplo de páginas anunciadas por email ou feed RSS, a utilidade vai bem além disso.
Se você tem um site, digamos de e-commerce, e tem uma página que ordena os produtos por preço, popularidade, etc, e essa ordenação é passada como parâmetro na URL, o conteúdo da página será essencialmente o mesmo, porém com a posição diferente (dependendo da ordenação). O buscador pode entender que a página é duplicada. Uma tag <link> como esta, apontando para a URL sem ordenação resolveria o problema.

Artigos relacionados

• Otimização: imagens inline
• Páginas de manutenção

Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

O problema

Digamos que na página principal do nosso site, a gente tenha um formulário de login mais ou menos assim:

<form action="login.php" method="post">
Login: <input type="text" name="login" />
Senha: <input type="password" name="senha" />
<input type="submit" />
</form>

Um formulário bem simples. E para tratar este formulário, temos o login.php, que vai checar em um banco de dados se o login e a senha estão corretos, da seguinte forma (colocarei apenas o trecho com a consulta SQL relevante):

<?php
$sql = "SELECT * FROM usuarios WHERE login = '{$_POST['login']}' AND senha = '{$_POST['senha']}'";
$res = mysql_query($sql);
if (mysql_num_rows($res) > 0) {
    print "Login OK";
}
else {
    print "Login e senha não conferem";
}
?>

Ou seja, verificamos na tabela usuarios se temos uma linha com o login e a senha fornecidos. Caso essa consulta retorne alguma coisa, significa que existe uma linha com o login e a senha fornecidos, caso contrário, não existe.
Se no formulário eu preencho o login com “joe” e a senha com “xxxx”, a seguinte consulta SQL será montada e executada:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx'

Porém, o que acontece se eu preecher o formulário com o login = joe, e a senha com: xxxx’ OR true –
Neste caso, teremos a seguinte consulta:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx' OR TRUE --'

Essa consulta vai retornar todas as linhas do banco de dados (por causa do “OR true” no final), e como a checagem no código é se a consulta retornou mais de uma linha, estaremos logados.
Existem formas mais sofisticadas de proceder com este tipo de ataque, mas o foco do artigo é na defesa.

FIEO

FIEO é uma técnica bastante usada para aumentar a segurança dos aplicativos web. Significa “Filter Input/Escape Output”, ou traduzindo, “Filtre a Entrada/Escape a Saída”.
O primeiro passo é a filtragem da entrada, já que a regra número 1 da segurança em aplicativos web diz que não podemos jamais confiar em informações vindas de fontes externas. No nosso caso, poderíamos fazer a filtragem do login e da senha checando se eles possuem apenas caracteres permitidos. Por exemplo, o site poderia ter uma regra especificando que o login deve conter apenas letras e números. A filtragem então, poderia ser feita usando a função ctype_alnum():

<?php
if (!ctype_alnum($_POST['login'])) {
    die("login possúi caracteres inválidos");
}
?>

Se o FI do FIEO lida com a filtragem da entrada, o EO lida com a manutenção da saída no contexto em que for lida.
Ou seja, FI garante que a nossa entrada é valida, e EO garante que quem quer que receba os nossos dados, irá interpretá-los da forma correta.
No nosso caso, é importante que as aspas simples não sejam interpretadas como delimitadores na consulta SQL. E se eu quisesse ter uma senha que tivesse uma aspa simples no meio?
Existem 3 formas clássicas de se resolver este problema.

Forma 1: addslashes() no PHP

É a forma mais simples (e ingênua) de se tratar o problema. Por exemplo, se queremos nos proteger das aspas simples, poderíamos simplesmente escapá-las no PHP da seguinte forma:

<?php
$login = addslashes($_POST['login']);
$senha = addslashes($_POST['senha']);
?>

Dessa forma, caso uma aspa simples chegasse do usuário, seria devidamente escapada com uma “\” antes, e o servidor SQL não iria interpretá-la como um delimitador.
Para o nosso exemplo de ataque, resolveria.
O grande problema com esta solução é que ela só prevê ataques que usem aspas simples. Bancos de dados diferentes podem usar caracteres de controle diferentes, como aspas duplas, quebras de linha, ou outras coisas mais estranhas. E checar por todas estas formas é longe de ser a maneira mais eficaz (e viável!) de se proceder.
Temos uma outra opção, suportada por vários bancos de dados.

Forma 2: deixar o próprio banco escapar

A segunda opção é passar a string para o banco e deixar ele se virar. Afinal, ele sabe o que pode e o que não pode entrar em uma string. No MySQL, isso poderia ser feito da seguinte forma:

<?php
$login = mysql_real_escape_string($_POST['login']);
$senha = mysql_real_escape_string($_POST['senha']);
?>

Segundo a documentação, chamando esta função, o banco escapa automaticamente as seguintes sequencias: \x00, \n, \r, \, ‘, ” e \x1a. Ou seja, pelo visto as aspas simples não eram nosso único problema mesmo.
Existem funções semelhantes para outros bancos de dados (por exemplo, pg_escape_string() para o PostgreSQL).
Porém, a solução que considero mais elegante é usar consultas preparadas.

Forma 3: consultas preparadas

A idéia de se preparar uma consulta é dizer ao banco de dados o formato da consulta (apenas os parâmetros formais), e fazer a amarração dos parâmetros reais somente na hora da execução.
A maior parte dos bancos de dados suportam consultas preparadas, mas vou mostrar o exemplo usando MySQL, devido a popularidade.

<?php
$dbh = new mysqli("localhost", "ususario", "senha", "banco");
$c = $dbh->prepare("SELECT * FROM usuarios WHERE login = ? AND senha = ?");
$c->bind_param("login", $_POST['login']);
$c->bind_param("senha", $_POST['senha']);
$c->execute();
?>

Ou seja, primeiro informamos ao banco qual será a consulta a ser executada. Perceba que usamos interrogações no lugar dos parâmetros reais. Com isso, o banco prepara a consulta pra ser executada.
Logo em seguida, dizemos ao banco o valor que cada parâmetro irá receber. Esta etapa se chama amarração (binding). Como o banco de dados sabe o tipo de cada campo, ele também sabe como proceder pra escapar corretamente cada valor.
E por último, executamos a consulta. Simples, fácil e seguro!

Conclusão

SQL Injection é um problema sério que afeta muitos aplicativos web por aí afora, porém é um problema que só existe por causa da ingenuidade dos programadores, que não programam pensando em segurança. A solução, como vimos, é bem simples.

Artigos relacionados

• Criando CAPTCHAs em PHP
• Segurança no envio de emails em PHP
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Os 10 piores CAPTCHAs do mundo
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP

<img src="imagem.png" />

ou então, podemos carregá-la como imagem de fundo de um elemento qualquer usando CSS:

.classe { background-image:url(imagem.png); }

Um dos problemas em páginas que possuem muitas imagens é que cada imagem requer a abertura de uma nova conexão HTTP, e com a limitação de 2 conexões por host (é uma restrição dos navegadores que seguem a especificação HTTP), o tempo de carga da página pode acabar crescendo bastante.

A lógica

Uma solução para este problema é ao invés de carregar as imagens externas, colocá-las diretamente dentro da página, seguindo a mesma lógica que já usamos com CSS. Por exemplo, podemos especificar uma folha de estilo externa:

<link rel="stylesheet" type="text/css" href="arquivo.css" />

ou então podemos colocar os estilos inline:

<style type="text/css">
.classe1 { font-color:#f00; }
#id2 { width:200px; }
</style>

Codificando a imagem

Até aí, tudo bem, afinal CSS é texto, e texto entra bem dentro de uma página. Mas como colocar uma imagem dentro de uma página, uma vez que a imagem é binária?
Simples! Primeiro, codificamos a imagem de binário para ASCII usando a codificação base64. Existem várias formas de se fazer isso, e boa parte das linguagens de programação disponibiliza funções para fazer esta codificação. Por exemplo, em PHP, podemos fazer:

<?php
print base64encode(file_get_contents("arquivo.png"));
?>

A saída disso é algo mais ou menos assim:

iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6
YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AF
uALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==

Pronto, já temos a representação codificada da imagem.
Para que a saída coubesse na tela, quebrei a saída em 3 linhas. A saída real é toda em uma só linha, mas como veremos adiante, tanto faz, pois podemos usar quebras de linha.

URLs do tipo “data”

Antes de colocarmos a imagem dentro da página, precisamos ver como funcionam as URLs do tipo “data”. A URL segue o seguinte formato:

data:[<tipo MIME>][;charset="<charset>"][;base64],<dados>

onde:

• tipo MIME é o tipo do arquivo que vamos colocar, no nosso caso, image/png;
• charset é a codificação utilizada, para o caso de arquivos texto (não usaremos no nosso exemplo).
• base64 é a codificação utilizada. Se for omitida, o navegador entenderá que estamos usando US-ASCII, e no caso de imagens, não vai dar certo;
• e por último, dados contém a string com o arquivo codificado (aquela sequencia grande de caracteres ali de cima). A string pode ser quebrada com espaços ou quebras de linha.

Juntando tudo

Pois bem, agora que temos a representação codificada da imagem e já sabemos usar URLs do tipo “data”, podemos colocá-la diretamente na página, usando a própria tag img:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZc
GAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6n
yt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==" />

Ou então uma regra de CSS, da seguinte forma:

.classe { background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUh
EUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0
AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7U
Z3wAAAABJRU5ErkJggg==); }

É claro que usar esta técnica, como quase tudo na vida, tem várias vantagens e desvantagens.

As vantagens

Temos várias vantagens em usar um esquema deste tipo:

• Suporte na grande maioria dos navegadores modernos: Firefox, Opera, Safari, Konqueror e Chrome;
• Antes de mais nada, estamos diminuindo o número de requisições HTTP, e consequentemente, evitamos o tráfego associado à requisição (cabeçalhos HTTP);
• Como a imagem está inline, conseguimos “fugir” do limite de 2 conexões por host, já que estamos evitando a abertura de novas conexões;
• Para imagens pequenas, temos um ganho real em bytes transferidos, pois embora a imagem codificada em base64 fique maior, estamos evitando de enviar os cabeçalhos HTTP (que somam em média 200 bytes).
• Conexões seguras (que usam https) só mostram o “cadeado” fechado se todos os elementos externos forem carregados através de https também. E o overhead associado a uma conexão https é bem maior que o de uma conexão http normal. Com a imagem inline, ganhamos mais um pouco.

As desvantagens

Temos várias desvantagens, algumas contornáveis:

• Internet Explorer até a versão 7 não tem suporte. Só a partir do 8. A forma de se usar para os dois navegadores é usando arquivos CSS separados para cada navegador (ou um pré-processador de CSS que detecte o navegador e dê a saída com o que for suportado);
• Imagem inline em uma página (usando tag img) não são cacheadas pelo navegador. Se usada dentro do CSS, aí sim teremos o cache em ação, pois o navegador irá cachear o CSS;
• Uma imagem codificada em base64 tem seu tamanho aumentado em 33%. Para imagens grandes, é uma perda considerável, mas para imagens pequenas (da ordem de 500 bytes), temos um ganho, pois mesmo com o aumento da imagem, estamos evitando o envio dos cabeçalhos, e podemos sair ganhando na soma;
• Dificuldade de manutenção: se uma imagem é alterada, ela precisa ser recodificada. Existem formas de se automatizar isso.

Um exemplo

A imagem que aparece aqui embaixo está inline, e foi colocada usando uma tag img (a qualidade está baixa pra não ficar muito grande):

Clicando o botão direito na imagem e escolhendo “Exibir imagem” (no Firefox ou em outro navegador que dê suporte), dá pra se ver na barra de endereços a URL usada pra criar a imagem.
E claro, se você não está vendo imagem nenhuma, provavelmente está usando o Internet Explorer. E já passou da hora de passar a usar um navegador decente, que suporta os padrões web, não é?

Artigos relacionados

• Evitando conteúdo duplicado
• Otimização de sites com memcached
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify