Sahb %)

Bom, outro dia sugeri ao super fotógrafo e guitarrista Sergio Buss que usasse um sistema de URL’s no site dele que fosse mais amigável. Como já ia escrever um pequeno passo a passo pra ele aplicar em seu blog, resolvi fazer um post, pra ajudar qualquer um que queira fazer isso também.

Começando

Se você tem um blog WordPress (como esse aqui ), provavelmente já deve ter notado que na instalação padrão, os links permanentes (permalinks) para seus posts e páginas são identificados como algo do tipo http://www.seusite.com.br/?p=221. Provavelmente também, deve ter reparado que algumas pessoas usam um sistema de url mais amigável, como http://www.seusite.com.br/2011/04/nome-do-post. Bem mais legal, né? Além de legal, os buscadores (principalmente o Google) adoram esse tipo de URL, e isso fará com que sua página apareça melhor colocada em buscas. Hoje vamos descobrir que fazer essa mágica da URL não é nada complicada.

Antes de começar a brincar com isso, certifique-se que seu servidor Apache tenha o mod_rewrite habilitado. Se você não sabe o que é mod_rewrite, nem o que é Apache, o suporte técnico da sua hospedagem saberá, daí você checa com eles se sua conta tem esse módulo (o mod_rewrite é um módulo). Estou sendo breve neste ponto porque praticamente todos os serviços de hospedagem têm esse módulo habilitado. Caso você tenha dificuldades, me avise que te ajudarei com mais detalhes.

Cuidado! Não são só flores!

Uma coisa importante a se fazer é garantir que você não perca o que conquistou nos resultados de pesquisa do Google. A estrutura nova de URL soará ao Google como novas páginas e as antigas terão desaparecido. Assim você voltará a idade da pedra, do ponto de vista dos buscadores. Mas nem tudo está perdido. Este plugin (dentro do admin WP, procure o plugin chamado Dean’s Permalinks Migration 1.0) permite que as URL’s antigas, se chamadas, redirecionem para a estrutura nova. Após instalá-lo e ativá-lo, é só ir em Configurações (ou Settings, em inglês), e de lá clique em PermalinksMigration. Coloque a regra que criava a estrutura antiga e salve. Se você não sabe qual é essa tal regra, vá em Configurações (Settings) e dentro dela, vá em Links permamentes (Permalinks). O campo Estrutura personalizada (ou Custom structure) irá conter a regra atual que gera seus links permamentes. Por exemplo, se seu site tinha a estrutura de links site.com/archives/5803, a regra nesse campo era /archives/%post_id%. É esse valor que você irá copiar e colar no PermalinksMigration. E assim, você agora está pronto para fazer a mágica das URL’s. Não prossiga se não tiver feito todos esses passos!

E agora, URL’s!

Chegou a hora de fazer seus links permanentes ficarem bonitões! Vá em Configurações (ou Settings, em inglês) e escolha o sub item Links permanentes (ou permalinks, em inglês). A mágica acontece na tela que carregará. Serão mostradas as opções de como sua url pode ficar. É bem auto explicativo. As opções fornecidas pelo WP por padrão, são as mais indicadas (eu por exemplo, uso a opção Mês e nome ou Month and name). Há a opção de fazer URL’s customizadas do tipo /%category%/%postname%/ (na notação dessa ferramenta), que é bem vista por muitas pessoas. Porém, por motivos de desempenho, prefira opções que antes de aparecer o nome do post, mostre um campo numérico. O sistema de Mês e nome é o mais bacana, a meu ver, porque esse campo numérico tem um valor que diz alguma coisa (é o ano e o mês de publicação), ao invés de um número arbitrário do id do post. Após selecionar a opção de mês e nome, clique em salvar. Lembre-se de testar se os links antigos estão funcionando corretamente, apontando para a estrutura nova, caso não estejam, volte rapidamente para sua configuração antiga, de links permanentes e cheque o que aconteceu de errado. Qualquer dúvida, me procure.

É isso então pessoal. Hoje aprendemos um jeito bacana de melhorar tanto a legibilidade das nossas URL’s, quanto a nossa relevância nos sites de busca. Espero que seja útil!

[]‘s

Sahb,.

Bom, conforme prometido, vamos dando sequência à série sobre segurança. Dessa vez serei bem breve, pois gostaria apenas de fazer um adendo importante ao post anterior. Eu tinha para mim, que era consenso que as pessoas sabiam fazer queries SQL de maneira correta e segura. Em especial, estou falando das queries que buscam id’s, ou qualquer dado inteiro, que não necessite de aspas para delimitar o valor. Pelo visto, pouca gente sabe, mas nesses casos, as aspas são opcionais. Sim, opcionais. Mas por que eu estou falando isso?

Você provavelmente já fez algum site que recebesse um parâmetro por GET do tipo noticias.php?id=2 , certo? E lá na sua query, você fazia todo feliz:

SELECT titulo,data,conteudo,autor FROM noticias WHERE id=$_GET['id'];

Aí, você leu meu artigo anterior sobre segurança e foi todo meninão (ou meninona, existem muitas mulheres programadoras ) colocar o seu mais novo amigo em ação, o mysql_real_escape_string(). Daí você passou a usar essa função a torto e a direito, achando que estava seguro. Aí um belo dia, você descobre que foi alvo de SQL Injection e me xinga todo, até a décima quarta geração… Pera lá! A tal função é muito útil, mas não é uma bala de prata.

A mysql_real_escape_string() serve para ‘escapar’ aspas de strings passadas para queries SQL, basicamente. Bão, pra uma query como a citada, o valor não é delimitado por aspas, então o atacante nem precisa se preocupar em burlá-las… Perceberam agora o problema?

Pelo que eu vi, muita gente não tem essa maldade, então sugiro que tenham… Outro dia vi um menino muito chato fazendo um noticia.php?id=2 or 1=1 e essa query pesou tanto o sistema que o site travou. Falei esse exemplo porque na maioria dos casos, esse ataque nem causa estragos, então não vão me condenar por criar monstrinhos… Bom, última chance pra você entender o que aconteceu. Fazendo aquela chamada, a query executada foi:

SELECT titulo,data,conteudo,autor FROM noticias WHERE id=2 or 1=1

Ou seja, retornaremos todos os registros do banco. Se os dados são um pouco mais complexos, e a query consulta várias tabelas, isso deitaria o servidor sem muita dificuldade.

Mas e aí? Coloque a tal aspa opcional, e junto com a nossa célebre amiga mysql_real_escape_string(), você estará mais alguns passos próximo de um site mais seguro =D

Resumindo, faça:

$query = sprintf("SELECT titulo,data,conteudo,autor FROM
     noticias WHERE id='%s';", mysql_real_escape_string($_GET['id']));

Acho que fui claro. Qualquer coisa, estou às ordens nos comentários. Depois tem mais.

[]‘s

Sahb,.

Depois de muito tempo sem postar, eis que volto %) Estou trabalhando aqui na 5Clicks agora. Uma experiência muito bacana, trabalhando com coisas legais. Depois rola um post só pra puxar o saco da 5′. hehehe

Bom, vamos ao que interessa. Hoje me deparei com um problema que muitos devem passar por aí, e vejo que a maioria prefere se adaptar ao inconveniente a corrigí-lo. De fato, é meio chatinho achar a resposta para a pergunta, mas antes de me adentrar na solução, acho que seria legal eu falar qual é o problema.

Codificação. Sim, se você programa ou faz alguma coisa pra web, já teve dor de cabeça com os ISO-8859-1 (ou latin1), UTF-8, etc… Antes que seus olhos encham de lágrimas e seu coração pule de alegria, não se engane: não irei resolver todos os seus problemas de codificação (a menos que todos os seus problemas se resumam no problema que irei listar aqui, mas aí, ah, que sem graça… )

Tá, qual é o problema? Bom, o nosso querido MySQL retorna por padrão (pelo menos até onde sei, os comentários estão aí para corrigir as besteiras que eu falo também) na codificação latin1. Então, independente de como os dados são adicionados, ele sempre retorna em latin1. Com isso, numa pesquisa feita ao banco, se impressa na tela em uma página em UTF-8, o resultado da consulta vai mostrar as malditas interrogações de erro de codificação. O latin1 é bacana, o latin1 é legal, mas utf-8 foi criado pra unificar essa bagunça de codificações (aguardem um post só pra defender o unicode). Então, já que inventaram essa codificação pra facilitar nossa vida, que a usemos então!

Muitas pessoas passam a usar páginas iso-8859-1 por não saber como fazer o queridíssimo MySQL retornar em outra codificação. Bom, não é difícil achar isso, com algum empenho dá pra achar como, tanto que eu nem sou um gênio e achei . O problema em achar essa resposta, é que se costuma fazer uma pesquisa do tipo “codificação mysql utf8″. Isso retorna muitos resultados em como mudar a “collation” do banco. Daí, um colega com menos empenho ou com um prazo apertando o pescoço (acho que isso ocorre a maioria das vezes), acaba sucumbindo em não conseguir resolver isso, e faz a página toda em iso-8859-1.

E agora, sem mais delongas, uma solução bacaninha pra mudar o retorno do banco de dados MySQL pra unicode. Basta passar o seguinte comando toda vez que uma conexão ao banco for criada:

SET NAMES 'utf8';

Não entendeu? Tipo, você está lá, fazendo sua conexão ao banco, no PHP por exemplo, daí você faz:

$conexao = mysql_connect($host,$usuario,$senha);
mysql_select_db($database);
mysql_query("SET NAMES 'utf8'");

É só fazer isso %) E sigam usando seu unicode felizes e contentes. Depois vou postar mais dicas pra lidar com a codificação, um assunto que dá muita dor de cabeça pra muuuita gente.

Espero que tenha ajudado!

[]‘s

Sahb,.