URLs Amigáveis - Path para imagens, scripts e css

Postado em PHP por tmferreira em 31/10/2007

13 Comentários

Breadcrumb Navigation: Navegação em Categorias

Postado em PHP, Banco de Dados por tmferreira em 27/10/2007

Fala galera!!

Depois de 60 dias da minha promessa de fazer este artigo….

Ando muito atarefado e sem tempo (graças a Deus) e por isso estou ausente do blog. Desculpem!

Quando você visualizando um produto num site qualquer, como o Mercado Livre, normalmente lhe é mostrado algo como:

Informática Notebooks e Laptops AMD Turion 64 X2 HP e CompaqHP TX1119us

Isto diz, para o usuário, que ele está visualizando um Notebook com processador AMD Turion 64 X2 dos fabricantes HP e Compaq e com modelo HP TX1119us. Instintivamente, se o usuário quiser ver todos os notebooks com este processador, independente de marca, ele clicará no link que está escrito o nome do processador. Da mesma forma, se quiser ver todos os modelos de notebooks HP ou Compaq, clicará no link correspondente.

Como Fazer

Vou basear o código para demonstração do Breadcrumb no artigo Categorias e sub-categorias, um erro comum.

Como todo script que percorrerá um número indefinido de níveis de hierarquia, existem duas possibilidades: fazê-lo recursivamente ou iterativamente. No artigo citado acima, utilizei um codigo recursivo. Para ser mais didático e democrático, dessa vez preferi utilizar um código iterativo.

Eis o código comentado:
<?php #Resgata o valor da categoria passada pela query string $cat = isset( $_GET['cat'] ) ? abs( intval( $_GET['cat'] ) ) : '1'; #Array que conterá o breadcrumb $breadcrumb = array(); #Inclui o arquivo de abstração de banco de dados require_once( 'class.bd.php' ); #Cria o objeto que manipulará o BD $bd = new bd(); #Query SQL para resgatar os dados da categoria passada pela query string $sql = 'select * from locais where ativo=\'S\' and id='.$cat; #Executa a query SQL $query = $bd->query( $sql ); #Se a categoria passada não existir if ( $bd->num_rows( $query ) == 0 ) { #Assume que a categoria será a padrão (default) $cat = 1; $breadcrumb[] = array( 'titulo' => 'Raiz', 'id' => $cat ); } #Se não é a categoria padrão if ( $cat != 1 ) { #Resgata os dados da categoria $campos = $bd->fetch_assoc( $query ); #Faça do { #Adiciona ao array breadcrumb os dados $breadcrumb[] = $campos; #Query SQL para resgatar os dados da categoria pai $sql = 'select * from locais where ativo = \'S\' and id = (select id_pai from locais where id = '.$campos['id'].')'; #Executa a Query SQL $query = $bd->query( $sql ); #Resgata os dados da categoria pai $campos = $bd->fetch_assoc( $query ); #Enquanto o número de linhas for diferente de 0 } while ( $bd->num_rows( $query ) != 0 ); } #Inverte o array breadcrumb $breadcrumb = array_reverse( $breadcrumb ); #Iniciliza a variável de saída $saida = ''; #Percorre todos os itens do breadcrumb foreach( $breadcrumb as $chave => $dados ) { #Monta a string de saída $saida .= '<a href="?cat='.$dados['id'].'" title="'.$dados['titulo'].'">'.$dados['titulo'].'</a> » '; } #Remove de $saida o elemento separados $saida = substr( $saida, 0, -3 ); #Exibe a saida echo 'Você está em: '.$saida; ?>

A saída será bem parecida com o exemplo que dei na introdução do artigo.

Como é de praxe, para utilizar os meus códigos normalmente você precisará fazer adaptações: tabelas e campos do banco de dados, strings de conexão, css, html, etc.

Se restar dúvida, só perguntar…

Abraços a todos e desculpem a demora, mais uma vez.

tmferreira

0 Comentários

YSlow: Melhore a Performance do seu Website

Postado em Performance por tmferreira em 06/09/2007

Olá, pessoal!!!

O YSlow é uma ferramenta de perfomace para web, desenvolvido pela equipe de desenvolvimento do Yahoo!. Ela segue as melhores práticas de web performance para front-end, adotadas pela equipe de performance do Yahoo!.

Seu funcionamento é integrado ao plugin FireBug, para o browser Firefox. Portanto, antes de instalar o YSlow no Firefox, é necessário instalar o Firebug.

Este artigo não é uma tradução mas é baseado nas regras de performance do YSlow, disponíveis da documentação da ferramenta. Além de trechos de adaptados do link original, há opiniões, comentários e conclusões deste que vos “fala”.

Mas, por que a performance do front-end é importante?

Tempo de resposta
A imagem acima é o resultado de tempo de carregamento de cada componente da página inicial do Yahoo!. Ela nos mostra que apenas 5% do tempo de carregamento da página foi gasto com o download do código HTML. Os outros 95% foram gastos com imagens, CSS, Javascripts, etc..

Uma pesquisa mostrou que 9 dos 10 maiores sites americanos têm, no máximo, 20% do tempo de carregamento gasto com HTML.

Isso nos indica que devemos cuidar da performance do front-end das nossas páginas WEB, a fim de melhorar a experiência do visitante.

As três principais razões para começar pela performance do front-end, segundo os especialistas em performance do Yahoo!:

Há mais potencial de melhoria de performance no front-end. Melhorar a performance do front-end pela metade reduz em 40% o tempo de resposta, enquanto melhorar pela metade a performance do back-end reduz apenas 10% do tempo de resposta.
A melhoria de performance através do front-end tipicamente requer menos tempo e recursos do que o back-end.
É provado que o tuning de performance do front-end funciona! Mais do que 50 equipes do Yahoo! reduziram o tempo de resposta para o usuário em 25% ou mais, seguindo as melhores práticas da equipe de performance do Yahoo!.

Como é medida a performance de uma página?

Para medir a performance de uma página, o YSlow basea-se em 13 regras. De acordo com a taxa de aderência da página às regras, é dada uma pontuação de A a F para cada regra, onde A representa a nota máxima e F representa a nota mínima. Também é calculada a nota final, com a média das notas obtidas nas 13 regras.

O detalhamento das notas para cada página pode ser vista na aba Performance, do YSlow.

Algumas dessas regras, como veremos a seguir, são proibitivas para a maioria dos sites devido ao custo, complexidade ou freqüência de uso. Vamos às regras!

Regras para Alta Performance

As regras são classificadas de acordo com o seu grau de importância.

Regra 1: Fazer poucas requisições HTTP

Segundo Steve Souders, que é o CARA do time de performance do Yahoo!, 80% do tempo gasto por um usuário numa página é carregando o front-end e que a maior parte desse tempo de carregamento é tomado pelo download de imagens, scripts, css, flash, etc., como já vimos anteriormente.
Então, para melhorar a performance no carregamento da página é importante utilizarmos o menos possível de imagens, css, etc. Para isso, além de otimizar essas requisições fazendo somente as necessárias, pode-se utilizar técnicas citadas por ele:

1. Mapa de imagens: quando se tem imagens que podem ser “coladas” umas nas outras, pode-se utilizar mapas de imagens para se detectar onde foi efetuado o clique. Embora o tamanho da imagem unificada seja o mesmo da soma das imagens separadas, o número de requisições diminui. Assim, toda aquela burocracia do HTTP 1.1 para abrir uma conexão e fazer a requisição é diminuída.
2. CSS Sprites: podemos utilizar essa técnica quando há substituição de uma imagem por outra, quando passamos o mouse sobre a imagem, por exemplo. As duas imagens são colocadas num mesmo arquivo e, através de CSS só uma delas é mostrada ao usuário. Quando o mouse está sobre a imagem, ela é deslocada, sendo mostrada a parte que estava oculta. Isso dá a impressão que a imagem foi mudada, mas na verdade é a mesma imagem em outra posição.
3. Combinar os arquivos de script em um único arquivo. Também podemos fazer isso com arquivos de estilo (CSS).
Reduzir o número de requisições HTTP é o principal ponto para melhorar a experiência dos usuários que não estão com os arquivos da sua página em cache.

Mais em: Make Fewer HTTP Requests.

Regra 2: Utilizar CDN

CDN (Content Delivery Network) pode ser traduzido como “Entregador de Conteúdo na Rede”. Embora a (má) tradução tenha dificultado o entendimento, isso é simples de entender. Digamos que você tenha um site de acesso global, como YouTube. Suponha que os arquivos estejam num único servidor aqui no Brasil. Agora imaginem os usuários de outros países e continentes acessando esse conteúdo. O caminho é longo, certo? Caminho longo significa maior tempo para acesso e carga desses arquivos.

O CDN serve justamente para eliminar isso, pois trata-se de uma coleção de servidores de conteúdo distribuídos geográficamente, de forma a minimizar a distância entre o usuário e o conteúdo estático de seu site. O cálculo de proximidade entre usuário e conteúdo é calculado através de saltos (hops) de roteamento ou do tempo de resposta à solicitação.

Mas como eu havia dito antes, há regras do YSlow que são proibitivas pelo custo. Esse é o caso da Regra 2 que, além de ser cara, só é necessário para uma parcela pequena de sites.

Mais em: Use a Content Delivery Network.

Regra 3: Adicione Expires no cabeçalho

O cabeçalho Expires diz ao browser a data que os componentes daquela requisição irão expirar, ou seja, se você determina um prazo de 5 anos para uma página expirar, todos componentes nela contidos somente expirarão em 5 anos. Com isso, todos os componentes (imagens, CSS, scripts, Flash, etc.) serão colocados em cache e, nas próximas visitas, o número de requisições HTTP será menor pois os componentes poderão ser acessados diretamente do cache do browser.

Aí você pergunta: “Mas e se eu fizer uma alteração num componente?”. Se você fizer uma alteração, precisará alterar também o nome deste componente. É altamente recomendado que seja acrescentado nos nomes dos componentes informações de versão. Exemplo: estilo_1.css.
Quando você fizer uma alteração neste arquivo, basta alterar a numeração da versão, colocando estilo_2.css.

O uso da linha de código a seguir faz com que os componentes da página que a contém expirar somente em 2012.
[code][/code]
Acontece que o HTTP/1.1 não recomenda o uso de datas de expiração maiores do que um ano. Eu penso que realmente não há necessidade de ser maior do que um ano pois normalmente os caches são limpos pelos usuários com freqüência.

Não recomendo o uso dessa técnica durante o desenvolvimento do projeto pois será mais difícil corrigir bugs e fazer alterações.

Mais em: Add an Expires Header.

Regra 4: Compacte componentes

Esta regra de performance indica que é recomendado que os componentes sejam compactados através da requisição HTTP para que o tempo de resposta seja menor, fazendo com que os componentes sejam carregados mais rapidamente no cliente.

A configuração da forma de compactação e o algoritmo de compactação utilizados variam de acordo com o servidor WEB utilizado.

A compactação é recomendada para qualquer arquivo de texto, como HTML, Javascript, folhas de estilo, XML, JSON, etc. Ela só não é recomendada para alguns tipos de arquivos como imagens e PDF, pois eles já são comprimidos e a compactação seria ineficiente e tomaria recursos do servidor desnecessariamente.

Mais em: Gzip Components.

Regra 5: Coloque o CSS no topo

Essa é uma das regras mais simples de seguir. Ela diz que a declaração das folhas de estilo (CSS) deve estar dentro do HEAD do documento. Isso é um tanto quanto óbvio, pois a especificação do HTML já diz isso.

O CSS deve estar no HEAD pois o browser pode renderizar o conteúdo de acordo com a progressão do carregamento dos componentes. Isso trás melhor experiência ao usuário pois ele, além de ver que algo está acontecendo, pode acessar um link que já tenha aparecido no browser antes mesmo da página terminar de carregar.

Quando o CSS não está no HEAD, alguns browsers esperam todo o carregamento da página, para que não tenha que haver reposicionamento ou redesenho de componentes. Enquanto não aparecem, o usuário vê somente uma página em branco. Browsers como o Firefox, que mostram o conteúdo independente do local de declaração do CSS, “correm o risco” de ter que redesenhar ou reposicionar os componentes na tela.

Mais em: Put CSS at the Top.

Regra 6: Coloque os scripts embaixo

Os arquivos externos de javascript funcionam da forma contrária aos arquivos CSS, quanto à renderização progressiva. Enquanto o CSS bloqueia a renderização de tudo o que está antes dele até seu carregamento completo, o javascript bloqueia o carregamento de tudo o que está depois dele, até o seu carregamento.

Assim, se você colocar os arquivos de script o mais próximo possível da tag de fechamento do BODY, a renderização de tudo o que está antes do script poderá ser feita independente do carregamento desses arquivos.

Outro fator que justifica a colocação dos scripts tão próximo do fechamento de BODY quanto possível é que os browsers não fazem download de nenhum outro arquivo enquanto fazem o download de um script javascript, independente se é do mesmo servidor ou não.

Eu até achava que os scripts não poderiam ser colocados dentro do BODY, mas, depois que li essa regra, fiz uma pesquisa e constatei que a especificação do HTML não tem nenhuma contra-indicação quanto a isso.

Mais em: Move Scripts to the Bottom.

Regra 7: Evite expressões CSS

É possível declarar expressões em CSS através do método expression. Uma expressão CSS utiliza javascript para calcular algum valor que será utilizado como valor de uma propriedade. Um exemplo de expressão CSS:
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
Além das expressões CSS só funcionarem no Internet Explorer, também há outro problema envolvido: diferentemente do que se possa imaginar, as expressões não são calculadas apenas ao carregar da página ou quando se redimensiona a janela. Elas também são calculadas a cada movimento do mouse sobre a página e quando movemos a barra de rolagem. Se a cada movimento do mouse sobre a tela geramos um cálculo dessa expressão, o movimento horizontal retilíneo de um extremo ao outro de uma página com resolução de 800 x 600 gera 800 cálculos!!!

Se realmente for necessário utilizar expressões CSS, prefira colocar essa expressão no arquivo javascript e setar a propriedade CSS através do Javascript. A vantagem é que você controlará os eventos que manipularão esse cálculo.

Mais em: Avoid CSS Expressions.

Regra 8: Utilize CSS e Javascript em arquivos externos

Em algumas regras anteriores falamos sobre a gerência de arquivos externos pelo HTTP. Aparentemente, há uma recomendação para que os códigos javascript e CSS sejam colocados no mesmo arquivo do código HTML, para diminuir o número de requisições HTTP. Mas não é bem assim!!

Colocar o javascript e CSS em arquivos separados, além de facilitar o reuso e manutenção desses arquivos, possibilitam que o navegador mantenha esses arquivos em cache.

Por outro lado, o javascript e CSS colocados “inline” no HTML não podem ser colocados em cache e têm que ser carregados a cada requisição. Outro fator contrário ao “inline” é que aumentam o tamanho do arquivo HTML e, por conseqüência, o tempo de carregamento desses arquivos.

Por outro lado (quantos lados, hein!), páginas que tem um estilo “único” dentre as outras páginas e normalmente são acessadas apenas uma vez por sessão devem ter seus javascript e CSS “inline”, desde que não sejam muito grandes.

Mais em: Make JavaScript and CSS External.

Regra 9: Reduza as pesquisas DNS

O DNS mapeia hostnames em endereços IPs para que possam ser feitas as conexões HTTP, assim como uma agenda telefônica mapeia nomes em números telefônicos.
Quando você digita www.tmferreira.com.br/blog/ no seu browser, antes de qualquer coisa, o seu browser solicita ao DNS o IP de www.tmferreira.com.br.

O cache de DNS em sistemas operacionais ou browsers expira rapidamente. Assim, é recomendado que não sejam utilizados muitos hostnames para um website, para que seja reduzido o tempo em pesquisas DNS.

Se você, assim como eu, tem um e-mail do BOL, já deve ter percebido que eles utilizam muitos hostnames. Isso melhora o tempo de carregamento das páginas com os downloads simultâneos, mas aumenta o número de pesquisas DNS.

Essa também é uma das regras que havia mencionado que não se aplicam a grande maioria dos sites, que tem o mesmo hostname para a aplicação toda.

Mais em: Reduce DNS Lookups.

Regra 10: Reduza os Javascripts

Essa regra preconiza que os arquivos javascript em produção devem ser reduzidos. A redução consiste em remover espaços, tabulações, comentários, etc., ou seja, tudo o que não é necessário para o funcionamento do código e que aumentam o tamanho dos arquivos.

Essa técnica é muito utilizada em scripts e frameworks distribuídos na internet. Essas distribuições normalmente são chamadas de packs.

A redução de scripts não tem efeitos colaterais e é indicada sempre que o arquivo já está em produção. Durante o desenvolvimento, a redução dificulta a alteração do código e remoção de bugs.

Mais em: Minify JavaScript.

Regra 11: Evite redirecionamentos

Os redirecionamentos acontecem pelos mais diversos motivos. A aplicação que mais vejo acontece em fóruns. Após você fazer um post, é mostrada uma mensagem (de sucesso ou erro) e depois há o redirecionamento para outra página.

Obviamente que isso deixa aborrecido os usuários que estão acessando de uma conexão lenta.

No iMasters, retiramos o redirecionamento para que a experiência do usuário seja melhor.

Mas há ocasiões em que não dá para escapar do redirecionamento. No meu blog, houve mudança de domínio. Como fazer com que os links do domínio antigo continuassem íntegros? Só com redirecionamento mesmo. Mas há formas e formas de fazer um redirecionamento. A mais rápida e recomendada é diretamente através de um cabeçalho HTTP com resposta 301 ou 302 (no blog foi feito assim). Uma forma de redirecionamento que é mais lenta é através da tag meta refresh.

O importante é ter bom senso e utilizar os redirecionamentos onde é extritamente necessário.

Mais em:
Avoid Redirects.

Regra 12: Remova scripts duplicados

Essa regra diz que não devemos fazer inclusões duplicadas (ou triplicadas, …) de scripts.

Eu não considero isso como uma regra pois não faz o menor sentido em incluir um mesmo script duas ou mais vezes na mesma página. Para mim, isso é um erro e nem precisaria de regra para que os desenvolvedores não o cometam.

Mais em: Remove Duplicate Scripts.

Regra 13: Configure ETags

ETags é o acrônimo para Entity Tags. Isto é um mecanismo que servidores WEB e browsers usam para determinar se o arquivo do servidor é o mesmo que está no cache do browser.

O valor da ETag é gerado dependendo das configurações do servidor e de acordo com as características atuais do arquivo.

Se você utiliza o Apache, pode configurar a diretiva FileEtag como eu utilizo:
FileEtag MTime
A linha acima pode ser colocada diretamente nos arquivos httpd.conf ou .htaccess.

Essa configuração faz com que o Apache calcule um hash do arquivo baseado na data e hora da sua última modificação. O browser armazena essa ETag em cache. Se eu modificar o arquivo e salvá-lo, a data e hora da última modificação será alterada e, com isso, os valores de ETag entre servidor e browser ficarão diferentes, fazendo com que o arquivo seja recarregado.

A configuração de ETags torna desnecessário o uso de versão no nome dos arquivos de imagens, CSS, Javascript, etc.

Mais em: Configure ETags.

Conclusão

Nesse artigo, vimos que o YSlow pode nos dar o caminho das pedras para diminuir o tempo de carregamento das páginas e melhorar a experiência dos visitantes.

Eu não encaro essas regras literalmente. Encaro-as como boas práticas que devem ser seguidas com bom senso e com análise caso a caso. Penso que a nota C é uma ótima nota para a grande maioria dos sites.

Abraços a todos(as)!

tmferreira

9 Comentários

Repente do iMasters: Classe de Manipulação de Datas

Postado em PHP por tmferreira em 06/09/2007

Olá, pessoal!! Vérspera de feriado… que beleza!

No mês passado aconteceu o primeiro Repente de PHP do Fórum iMasters. O Repente é uma idéia do meu amigo Anderson Mello, que consiste num duelo entre dois competidores no estilo dos repentes musicais do nordeste ou da batalha de DJs do sudeste.

Cada Repentista deve melhorar o código do “rival”, deixando o script com cada vez mais performance e menor código. A intenção, mais do que tudo, é aprender e se divertir. Mais sobre os repentes.

O primeiro repente foi entre mim e o autor da idéia, Anderson. Fizemos um repente sobre classe de manipulação de datas. A classe deveria ser em PHP5, não utilizar as funções nativas do PHP para manipulação de datas e horas e ser capaz de validar uma data no formato dd/mm/aaaa, somar ou subtrair dias, meses e/ou anos a uma data.

O código da classe final está abaixo:
<?php class Data { private $data; /** * Construtor */ public function __construct($data = '') { /* Instancia objeto com a data informada Se nenhuma data for informada, será definida a data atual do sistema no formato d/m/Y */ $this->data = ( !empty( $data ) ) ? $data : date('d/m/Y', time()); } public function __toString() { return $this->data; } private function addAno( &$dt, $quant ) { $dt[2] += $quant; if ( $this->validar( $dt[0]."/".$dt[1]."/".$dt[2] ) ) { return $dt[0]."/".$dt[1]."/".$dt[2]; } $dt[0] = "01"; $dt[1] = "03"; return $dt[0]."/".$dt[1]."/".$dt[2]; } private function addMes( &$dt, $quant ) { $dt[1] += $quant; if ( $dt[1] > 12 ) { $dt[2] += floor( $dt[1] / 12 ); $dt[1] = $dt[1] % 12; } if ( $this->validar( $dt[0]."/".$dt[1]."/".$dt[2] ) ) { return $dt[0]."/".sprintf( "%02d", $dt[1] )."/".$dt[2]; } $dt[0] = "01"; return $dt[0]."/".sprintf( "%02d", ++$dt[1] )."/".$dt[2]; } private function addDia( &$dt, $quant ) { $aux = $dt[0]; $dt[0] += $quant; if ( $this->validar( $dt[0]."/".$dt[1]."/".$dt[2] ) ) { return $dt[0]."/".$dt[1]."/".$dt[2]; } if ( $dt[0] <= 31 ) { $dt[0] = "01"; return $dt[0]."/".sprintf( "%02d", ++$dt[1] )."/".$dt[2]; } $ultimo_dia = array( 1 => 31, 2 => 28, 3 => 31, 4 => 30, 5 => 31, 6 => 30, 7 => 31, 8 => 31, 9 => 30, 10 => 31, 11 => 30, 12 => 31 ); $quant -= $ultimo_dia[(int)$dt[1]] - $aux; $dt[1]++; while ( $quant > 31 ) { $quant -= ( $dt[1] == 2 && $dt[2] % 4 == 0 ) ? $ultimo_dia[$dt[1]] + 1 : $ultimo_dia[$dt[1]]; $dt[1]++; if ( $dt[1] > 12 ) { $dt[2]++; $dt[1] = 1; } } $dt[0] = $quant; if ( $this->validar( $dt[0].”/”.$dt[1].”/”.$dt[2] ) ) { return sprintf( “%02d”, $dt[0] ).”/”.sprintf( “%02d”, $dt[1] ).”/”.$dt[2]; } $dt[0] = “01″; return $dt[0].”/”.sprintf( “%02d”, ++$dt[1] ).”/”.$dt[2]; } private function subAno( &$dt, $quant ) { $dt[2] -= $quant; if ( $this->validar( $dt[0].”/”.$dt[1].”/”.$dt[2] ) ) { return $dt[0].”/”.$dt[1].”/”.$dt[2]; } $dt[0] = “01″; $dt[1] = “03″; return $dt[0].”/”.$dt[1].”/”.$dt[2]; } private function subMes( &$dt, $quant ) { $dt[1] -= $quant; if ( $dt[1] == 0 ) { $dt[2]–; $dt[1] = 12; } if ( $dt[1] < 0 ) { $dt[1] = abs( $dt[1] ); $dt[2] -= ceil( $dt[1] / 12 ); $dt[1] = 12 - ( $dt[1] % 12 ); } if ( $this->validar( $dt[0].”/”.$dt[1].”/”.$dt[2] ) ) { return $dt[0].”/”.sprintf( “%02d”, $dt[1] ).”/”.$dt[2]; } $dt[0] = “01″; return $dt[0].”/”.sprintf( “%02d”, ++$dt[1] ).”/”.$dt[2]; } private function subDia( &$dt, $quant ) { $aux = $dt[0]; $dt[0] -= $quant; if ( $this->validar( $dt[0].”/”.$dt[1].”/”.$dt[2] ) ) { return sprintf( “%02d”, $dt[0] ).”/”.$dt[1].”/”.$dt[2]; } $ultimo_dia = array( 1 => 31, 2 => 28, 3 => 31, 4 => 30, 5 => 31, 6 => 30, 7 => 31, 8 => 31, 9 => 30, 10 => 31, 11 => 30, 12 => 31 ); if ( $dt[0] == 0 ) { $dt[1]–; if ( $dt[1] == 0 ) { $dt[1] = 12; $dt[2]–; } $dt[0] = ( $dt[1] == 2 && $dt[2] % 4 == 0 ) ? $ultimo_dia[(int)$dt[1]] + 1 : $ultimo_dia[(int)$dt[1]]; return $dt[0].”/”.sprintf( “%02d”, $dt[1] ).”/”.$dt[2]; } $quant -= $aux; while ( $quant >= 0 ) { $dt[1]–; if ( $dt[1] < 1 ) { $dt[2]--; $dt[1] = 12; } $quant -= ( $dt[1] == 2 && $dt[2] % 4 == 0 ) ? $ultimo_dia[$dt[1]] + 1 : $ultimo_dia[$dt[1]]; } $dt[0] = abs( $quant ); while ( !$this->validar( $dt[0].”/”.$dt[1].”/”.$dt[2] ) ) { $dt[0] = abs( $dt[0] - 1 ); } return sprintf( “%02d”, $dt[0] ).”/”.sprintf( “%02d”, $dt[1] ).”/”.$dt[2]; } public function operar( $param, $data = ” ) { if ( empty( $data ) ) { $data = $this->data; } if ( !($match = $this->validar( $data )) ) { return false; } $param = explode( ” “, $param ); $tipos = array( “d” => “Dia”, “m” => “Mes”, “a” => “Ano” ); foreach ( $param as $c => $v ) { if ( preg_match( ‘/^([-+0-9]*)([adm]{1})$/’, $v, $m ) ) { $operacao = ( $m[1] >= 0 ) ? “add” : “sub”; if ( method_exists( $this, $operacao.$tipos[$m[2]] ) ) { $this->{$operacao.$tipos[$m[2]]}( $match, abs( intval( $m[1] ) ) ); } } } return sprintf( “%02d”, $match[0] ).”/”.sprintf( “%02d”, $match[1] ).”/”.$match[2]; } function validar( $data = ” ) { if ( empty( $data ) ) { $data = $this->data; } $match = explode( “/”, $data ); if ( $match[0] <= 0 || $match[0] > 31 || $match[1] <= 0 || $match[1] > 12 || ( $match[0] == 31 && ( $match[1] == 4 || $match[1] == 6 || $match[1] == 9 || $match[1] == 11 ) ) || ( ( $match[1] == 2 ) && ( ( $match[2] % 4 == 0 && $match[0] > 29 ) || ( $match[2] % 4 != 0 && $match[0] > 28 ) ) ) || $match[2] < 1000 || $match[2] > 3000 ) { return false; } return $match; } }//fim da classe ?>
Para testá-la, podemos utilizar o código:
<?php $data = new Data('20/04/2006'); $valido = $data->operar('20d 2m 2a'); //mais 20 dias, mais 2 meses, mais 2 anos $valido = $data->operar('20d'); //mais 20 dias $valido = $data->operar('2m'); //mais 2 anos $valido = $data->operar('2a'); //mais 2 anos $valido = $data->operar('20d -2m -2a'); //mais 20 dias, menos 2 meses, menos 2 anos echo "<br />$valido";

É óbvio que com as funções nativas do PHP ficaria muito mais fácil, mas não seria tão divertido! rsrsrsrsrs

Abraços,

tmferreira

6 Comentários

LightTPD - Atenção para este servidor WEB

Postado em Servidor por tmferreira em 03/09/2007

Olá, pessoal!

Estava pesquisando sobre estatísticas de utilização de servidores WEB, quando encontrei este comparativo de Abril de 2007 no site da Netcraft.

Me chamou a atenção o comentário feito pela Netcraft, onde foi dito resumidamente que, apartir do mês de Abril de 2007, estavam incluindo na pesquisa o LightTPD, que é um servidor WEB open source desenvolvido para sites de alta performance. Disseram ainda que o LightTPD permite um grande número de conexões paralelas, fazendo com que seja perfeito para sites que usam muito AJAX ou Ruby On Rails.

O LightTPD já entrou na pesquisa desbancando o NCSA e encostando no servidor web da SUN.

A popularidade do LightTPD está crescendo e ele já é usado como servidor primário por nada menos do que SourceForge (maior site para desenvolvimento de projetos open source) e Meebo (acesso a serviço de mensagens instantâneas sem instalação dos softwares tradicionais, como MSN, ICQ, etc), além de servir como servidor off-load de sites como YouTube, Wikipedia, MySpace, ImageShack, etc.
A lista com os sites que informaram formalmente que utilizam LightTPD pode ser vista neste link.

Mudando o rumo da minha pesquisa para o LightTPD, vi que ele é servidor de 1,5 Milhões de sites!

Este servidor tem importantes módulos, como mod_compress, que faz a compressão de arquivos estáticos (arquivos de imagens, estilo, script, etc.) e permite a redução de tráfego na rede e mod_rewrite, que faz rescrita de URL (semelhante ao mod_rewrite do Apache).

A documentação do LightTPD pode ser encontrada neste link.

Pelo pouco que mostrei e pelos usuários deste servidor, deu para ver que valhe a pena testá-lo. Eu já estou instalando….

Abraços,

tmferreira.

3 Comentários

Segurança: Algoritmo Diffie-Hellman

Postado em Javascript, PHP por tmferreira em 25/08/2007

Olá, pessoal!!

Embora eu não seja um aficionado por segurança, este tema me fascina. Sempre busco trazer mais segurança para os meus sistemas. Aliás, é dever do desenvolvedor buscar formas de garantir para seu cliente segurança da informação.

Pesquisando sobre métodos de criptografia, a fim de trafegar os dados entre cliente e aplicação (servidor) de forma segura, encontrei o algoritmo Diffie-Hellman.

Se você já configurou um roteador wireless, talvez tenha tido oportunidade de experimentar na prática o conceito de Pre-Shared Key (PSK), ou seja, uma chave secreta (que só o administrador da rede sabe) que será usada para criptografar os dados enviados entre o roteador e os computadores dessa rede e vice-versa.
Essa chave, é configurada no roteador e em TODOS os computadores que acessarão essa rede. Se o administrador quiser mudar a chave e tiver 100 computadores plugados na rede, deverá efetuar a mudança nos 100 computadores + o roteador.

Diante do problema de ter que trocar uma chave secreta entre cliente e servidor sem que “se conheçam” ou que seja necessário configurar um por um (individulamente), surge as perguntas: Como trocar chaves secretas dinamicamente?

A resposta para esse dilema é utilizar o algoritmo Diffie-Hellman para trocar essas chaves dinamicamente e de forma segura*.

O Algoritmo Diffie-Hellman

Saindo do exemplo da configuração da rede wireless, vamos tornar nosso exemplo mais amigável e acessível com o uso de dois personagens humanos muito famosos para quem estuda protocolos de comunicação de dados: Alice e Bob.

Imaginem que Alice e Bob queiram trocar e-mails secretos de forma segura*. Porém, os dois nunca tiveram oportunidade de combinar uma PSK (Pre-Shared key) de forma segura. Como fazer?

Suponha que Alice tenha mandado o seguinte e-mail para Bob:

Bob, vamos utilizar o algoritmo Diffie-Hellman para trocar uma chave pública. Esta chave, combinada com um algoritmo de criptografia AES (Advanced Encryption Standard), também conhecido por Rijndael, de 256 bits, fará com que o conteúdo de nossos e-mails sejam encriptados. Assim, só quem conhece a chave privada (que será gerada pelo algoritmo Diffie-Hellman e só nós vamos conhecer) poderá ler o e-mail. Ficou complicado? Vou te explicar como funciona o algoritmo Diffie-Hellman:
1. Eu escolherei dois números que utilizaremos em comum. A = 7 e B = 11.
2. Escolho um número que só eu sei, que chamarei de X. Você também escolhe um número (não conte a ninguém), chamado de Y.
3. Eu aplico a seguinte fórmula: Ra = (A^X) mod B. E vou te passar o resultado Ra.
4. Você aplica a mesma fórmula, substituindo X pelo seu número secreto Y. Rb = (A^Y) mod B. E você me passará o valor de Rb.
5. Agora, eu aplico a seguinte fórmula para descobrir nossa chave privada: PSK = (Rb^X) mod B.
6. Para você descobrir a chave privada, use a fórmula: PSK = (Ra^Y) mod B.
7. Agora, é só nos dois utilizarmos a chave privada como insumo na função de criptografia AES.

Não se preocupe em alguém saber A, B, Ra e Rb. Mesmo sabendo esses valores, ficará quase impossível alguém descobrir qual os números X ou Y que geraram a chave privada.

Qualquer dúvida me liga!

Alice.

Lendo apenas este e-mail que Alice enviou para Bob, talvez tenha sido difícil de entender. Não se preocupe: vou explicar melhor.

1. O primeiro passo é combinar dois números inteiros (A e B).
2. Cada um (Alice e Bob) escolhem um número inteiro secreto. Alice escolhe o número X e Bob escolhe o número Y.
3. Alice usa a fórmula: Ra = (A^X) mod B.
4. Bob usa a fórmula: Rb = (A^Y) mod B.
5. Alice divulga para Bob que o resultado foi Ra.
6. Bob divulga para Alice que o resultado foi Rb.
7. Alice usa a fórmula seguinte para descobrir a chave privada (PSK): PSK = (Rb^X) mod B.
8. Bob usa a fórmula seguinte para descobrir a chave privada (PSK): PSK = (Ra^Y) mod B.

A partir deste momento, se Alice enviar um e-mail para Bob encriptado por AES-256, utilizando a chave PSK, somente quem souber essa chave (Bob ou Alice) poderá desencriptar o e-mail e ler seu conteúdo.

Exemplo Prático

Continuando com o exemplo de Alice e Bob, vamos supor:
1. Que eles tenham combinado A = 7 e B = 11.
2. Que Alice tenha escolhido X = 6.
3. Que Bob tenha escolhido Y = 3.
4. Alice envia para Bob Ra = 4. [Ra = (7⁶) mod 11 => Ra = 4]
5. Bob envia para Alice Rb = 2. [Rb = (7³) mod 11 => Rb = 2]
6. Alice calcula PSK = 9. [PSK = (2⁶) mod 11 => PSK = 9]
7. Bob calcula PSK = 9. [PSK = (4³) mod 11 => PSK = 9]

A chave definida (PSK) é igual a 9.

Descobrindo a Chave

Para descobrir a chave calculada, é preciso utilizar a fórmula: PSK = (A^X*Y) mod B.

Como vocês podem ver, as combinações de pares X e Y são infinitas e é muito difícil que alguém consiga descobrir os dois números.

Considerações

Mesmo que se conheça A, B, Ra e Rb, não é possível descobrir PSK por outro método que não seja a “força bruta”, ou seja, testar cada valor de X e Y.

Num primeiro momento, pode parecer fácil para um computador testar em questão de minutos (ou mesmo horas) os valores possíveis e descobrir PSK.
Mas o exemplo acima foi meramente didático. Na prática, os valores de A, B, X e Y são grandes, na casa de pelo menos 6 dígitos.
Com números dessa grandeza, é necessário computadores “potentes” para executar esses cálculos.

Além disso, existem outros fatores matemáticos para a determinação de A, B, X e Y (que não são escopo deste artigo) que podem dificultar exponencialmente a descoberta de X e Y.

Conclusão

Neste artigo, vimos que o algoritmo Diffie-Hellman pode nos ajudar a estabelecer uma chave privada para encriptação dos dados que circulam na grande rede, dificultando que estes possam ser violados ou ter sua integridade corrompida.

Até!!!

tmferreira

* Dizer que um tipo de criptografia ou comunicação é segura não é o mesmo que dizer que é inviolável.

2 Comentários

Você é um humano?

Postado em PHP, Webstandards por tmferreira em 18/08/2007

Introdução

Olá, pessoal!

Muitas são as razões para se exigir alto grau de segurança num sistema, que vão desde a movimentação de valores num sistema bancário até a privacidade de informações de seus clientes.

Na busca por mais segurança, os desenvolvedores utilizam métodos para verificar se o “usuário” que está acessando o sistema ou recurso é um humano ou não. Os testes que têm como objetivo diferenciar um humano de uma máquina são chamados de Testes de Turing, criado pelo famoso cientista da computação Alan Turing.

Certamente, diferenciar um humano de uma máquina com eficiência aumenta o grau de segurança de uma aplicação. O problema é que há fatores importantes que devem ser levados em consideração na aplicação desses testes. O principal deles, na minha opinião, é a acessibilidade.

Também precisamos levar em consideração a eficiência dos testes. Sempre que há desenvolvedores buscando soluções de segurança, existem outros buscando meios de burlar a segurança. E quanto mais atrativo for o sistema para utilização “criminosa”, mais recursos serão despreendidos para quebrar a segurança.

Neste artigo, vou mostrar algumas alternativas para Testes de Turing.

Captcha

O mais famoso Teste de Turing aplicado na WEB certamente é o CAPTCHA. Um tipo comum de CAPTCHA é o uso de letras e números distorcidos sobre uma plano de fundo.

Para exemplificar, eu fiz um código para geração de CAPTCHA, utilizando PHP. Veja o código para geração do captcha, o código para verificação e o resultado final.

Existem muitos sistemas de Inteligência Artificial que foram desenvolvidos com o intuito de “ler” as imagens através de computadores e passar por essas barreiras de segurança. O mais impressionante é que normalmente os captchas que podem ser entendidos por humanos são quebrados por esses sistemas com um alto grau de eficiência - a maior parte dos captchas é quebrada em mais de 80% das tentativas. Assim, a sensação de segurança com a utilização de captcha normalmente é só uma sensação, pois, se o seu sistema realmente interessar, será despreendido tempo e recursos para a quebra de segurança.
Não quero, com isso, dizer que não há captchas eficientes. Existem captchas que até hoje nunca foram quebrados e provavelmente nunca serão, devido a sua complexidade.
O problema da complexidade é que muitos humanos também terão dificuldade de entender a imagem e acessar o sistema. Falando em acesso, pense num usuário cego se cadastrando num site que tenha captcha… Ele simplesmente não consiguirá se cadastrar e será marginalizado pelo sistema. Agora imagine que esse site seja da Receita Federal. Uma parte da população não poderá acessar um serviço público.

Esse problema pode ser contornado com a utilização de captchas sonoros combinados aos visuais. Mas se você conseguiu fazer um captcha visual eficiente, certamente terá muito mais dificuldade para ter a mesma eficiência com sons. Isso porque distorcer um som para impedi-lo de ser entendido por sistemas de reconhecimento de voz fará com que também fique difícil para humanos entender.

Também cabe sempre pensar nos usuários de navegadores baseados em texto.

Se decidir por utilizar CAPTCHA, tenha em mente que seu sistema terá a acessibilidade comprometida e que não estará 100% livre de invasores. Muito pelo contrário: se o invasor tiver muito interesse em acessar de forma automática, ele não enveredará esforços para conseguir exito e muito provavelmente conseguirá.

Testes de Lógica

Este tipo de teste também vem crescendo na WEB. Trata-se de uma pergunta que tem somente uma resposta lógica. Exemplo: “Qual dessas palavras é um nome de homem? Armário, Carro ou João?”.

Bastante interessante, não? É uma pergunta fácil de ser respondida por um humano porém difícil de ser respondida por um computador.

Se a pergunta não admitir somente uma resposta de múltipla escolha, como no exemplo acima, o sistema deve permitir flexibilidade de maiúsculas/minúsculas, acentos, espaços a mais, pontuação, etc.

Mas há desvantagens.

1. Você terá que ter um arsenal de milhares de perguntas e respostas. Imagine que você cadastre 100 perguntas e suas respectivas respostas. Em questão de minutos um computador testará todas as possibilidades e as cadastrará para futuro uso. Mesmo que não seja possível automatizar os testes com um computador, um humano pode responder às perguntas e “ensinar” ao computador as respostas.
2. Esse método também tem problemas de acessibilidade. Existem pessoas que têm problemas de cognição ou dislexia. Além disso, há os visitantes de outros países.

Verificação por e-mail

É um método interessante. O usuário cadastra-se através de um formulário comum mas a sua conta fica desabilitada até que o usuário confirme sua inscrição através de um e-mail enviado pelo sistema para o endereço cadastrado.

Embora dificulte, não impede. Se um humano completar o cadastro do robô, posteriormente ele (o robô) poderá acessar o sistema através de login automático.

A grande vantagem desse método é que ele é completamente acessível. Além disso, é simples de implementar.

Identificação por Documentos

Outra forma simples de implementar e acessível é a identificação do usuário por documentos (Identidade, CPF, cartão de crédito, etc). Esse método se assemelha ao anterior pela facilidade de implementação e da quebra de segurança.

Outro fator a ser levado em consideração é a segurança das informações dos usuários cadastrados e o uso de documentos de terceiros.

Coleta de Perfil

Uma forma complexa é a formação de um perfil de utilização do sistema para cada usuário. Muito utilizado por sistemas financeiros de instituições bancárias, consiste em monitorar os “passos” do usuário e estabelecer padrões de uso.

Digamos que você acessa o site do seu banco e faz sempre movimentações baixas, paga sempre os mesmos boletos, etc. Um dia outro usuário se faz passar por você e paga um título “estranho” de um valor alto, ou faz uma transferência para uma conta “estranha”. O sistema detecta que pode estar acontecendo uma invasão e alerta o administrador do sistema, que faz a investigação e toma as medidas necessárias.

Eu conheço usuários que já tiveram suas contas bloqueadas porque os administradores do sistema bancário identificaram a invasão antes que houvesse alguma fraude.

Como desvantagens, vejo o alto custo do sistema, monitoração de alertas, etc. Além disso, há um tempo necessário para a correta coleta do perfil do usuário. Essas desvantagens inviabilizam a utilização da coleta de perfil na maior parte dos sistemas WEB.

Chat ou Telefone

Imagine tentar acessar um serviço que requer segurança e, antes do acesso, ser submetido a um chat com um operador, para que você confirme que é um humano ou que você é o dono da conta.

Interessante, não?

Esse sistema é utilizado por alguns sites, que requerem que, após uma transação, você confirme através de telefone ou chat que realmente deseja continuar a transação.

Mais um sistema eficiente. Mais um sistema que é inviável, na maior parte das vezes, pelo alto custo.

Limitação de Utilização

Ainda tomando como exemplo sistemas financeiros, o seu sistema ter cotas de utilização. Exemplos:
1. Mandar 20 mensagens por dia.
2. Comprar no máximo R$500,00 por dia.

A desvantagem é que torna-se necessário um estudo detalhado para estabelecimento de cotas que permitam aos usuários corretos utilizar o sistema de forma satisfatória. O sistema também deve prever forma de contornar as cotas. Além disso, sempre haverá usuários que acharão que as cotas foram mal estabelecidas e ficarão insatisfeitos.

Conclusão

Vimos que um sistema infalível é difícil e custoso. Vimos principalmente que, ao contrário do que muitos pensam, CAPTCHA não é seguro, mas funciona para “invasores” inexperientes ou com poucos recursos.

O importante é levarmos em consideração a acessibilidade dos nossos sistemas. Pensar na parcela dos usuários que serão excluídos.

Seja criterioso na escolha do sistema “Você é um humano?”. Pense nos prós e contras, nas medidas para diminuir ou neutralizar os contras e, se os contras ainda existirem, se vale a pena conviver com eles.

Abraços a todos(as)!

tmferreira

9 Comentários

Nova Enquete - Onde Você Aprende?

Postado em Bate-papo por tmferreira em 14/08/2007

Pessoal, estou colocando mais uma enquete para vocês opinarem.

A última foi sobre o Fim do PHP4 e o resultado foi:

O PHP4 vai acabar?

Sim. Depois da entrada do PHP6. (31%, 4 Votes)

Sim, mas a forma de programar do PHP4 não. (31%, 4 Votes)

Sim. Eu não sei por que existe ainda. (23%, 3 Votes)

Não. Pouca gente precisa dos recursos das versões mais novas. (8%, 1 Votes)

Não. Os hosts não têm interesse. (8%, 1 Votes)

Total de Votos: 13

Loading …

Agora, estou perguntando sobre o tipo de local onde você costuma aprender sobre qualquer assunto relacionado ao desenvolvimento WEB.

Vocês podem ver a nova enquete na barra lateral à direita.

Sds,

tmferreira

4 Comentários

Register_globals - Por que mantê-la Off?

Postado em PHP por tmferreira em 14/08/2007

Saudações, galera!!

Estou um tempo sem escrever por causa do acúmulo de serviço mas estou preparando alguns artigos para postar. Antes destes, resolvi falar sobre a diretiva register_globals, do PHP.

Como voltei a freqüentar o fórum de PHP do iMasters para responder às dúvidas da galera, percebi que hoje ainda tem muita gente que programa dependendo desta diretiva.

Neste artigo, vou mostrar que register_globals não é nenhum bicho de sete cabeças mas que pode comprometer a segurança de sua aplicação. E se não comprometer a segurança, certamente comprometará a portabilidade e uso no futuro.

Diretiva register_globals

A diretiva (ou flag) register_globals está presente no arquivo php.ini, que é o arquivo de inicialização do PHP, ou seja, onde são definidas as configurações, extensões que serão carregadas, etc.

Ela pode ser definida como On ou Off diretamente no arquivo php.ini, através do .htaccess ou httpd.conf.

Quando definida como On, automaticamente são criadas vários tipos de variáveis, como as variáveis de formulários. Isso quer dizer que você pode usar na página do action de um formulário, as variáveis sem inicializá-las. Tomando como exemplo o trecho abaixo retirado de uma página index.php:
<form method="post" action="processa.php"> <fieldset> <legend>Formulário de Teste</legend> <label for="txtnome">Nome:</label> <input type="text" name="txtnome" id="txtnome" /> <input type="submit" name="btnsubmit" id="btnsubmit" /> </fieldset>
Na página processa.php, nós poderíamos utilizar a variável $txtnome diretamente:
<?php echo $txtnome; ?>
Num primeiro momento, isso nos parece muito bom e eficiente, mas há alguns problemas, como portabilidade e segurança da aplicação.

Portabilidade

Aproveitando o exemplo anterior, se register_globals estivesse definida como Off e a página processa.php permanecesse inalterada, não seria exibido o valor do input text e o PHP iria gerar um erro tipo Notice. Assim, para evitarmos problemas e mantermos a aplicação funcionando, precisamos alterar processa.php para:
<?php echo $_POST["txtnome"]; ?>
Isso nos mostra que, se mantivermos nossos scripts dependentes de register_globals = On, a nossa aplicação não será executada com sucesso num servidor em que a diretiva esteja definida como Off.

Por incrível que pareça, isso é uma falha muito comum, pois alguns programadores iniciando no aprendizado do PHP instalam o PHP 4, em que register_globals é On por padrão, desenvolvem suas aplicações em localhost e, quando instalam a aplicação num servidor de hospedagem com PHP 5, nada funciona. Isso acontece porque no PHP 5 a diretiva é Off por padrão.

Iniciar programando errado gera vícios que podem ser difíceis de ser tirados no futuro. Principalmente pelo fato de que, no PHP 6, a diretiva register_globals sequer irá existir (O fim da register_globals).

Segurança

Muito se diz que se register_globals estiver On o script é inseguro. Isso não é verdade! O script só estará inseguro se estiver On e não forem tomadas as medidas de controle que indico independente de como está setada a flag.

Um exemplo clássico de script inseguro e dependente de register_globals é (adaptado de Usando a diretiva Register Globals):
<?php // define $autorizado = true somente se o usuário for autenticado if (autenticar_usuario()) { $nbsp;$nbsp;$nbsp;$nbsp;$autorizado = true; } // Porque nós não inicializamos $authorized como false, ela pode ser // definida através de register_globals, como usando GET auth.php?autorizado=1 // Dessa maneira, qualquer um pode ser visto como autenticado! if ($autorizado) { $nbsp;$nbsp;$nbsp;$nbsp;include "/highly/sensitive/data.php"; } ?>
Se utilizarmos o mesmo script com as adaptações que sempre recomendo, como inicializar as variáveis, ele fica seguro.
<?php $autorizado = false; // define $autorizado = true somente se o usuário for autenticado if (autenticar_usuario()) { $nbsp;$nbsp;$nbsp;$nbsp;$autorizado = true; } // Porque nós não inicializamos $authorized como false, ela pode ser // definida através de register_globals, como usando GET auth.php?autorizado=1 // Dessa maneira, qualquer um pode ser visto como autenticado! if ($autorizado) { $nbsp;$nbsp;$nbsp;$nbsp;include "/highly/sensitive/data.php"; } ?>
Então, podemos ver que é possível utilizar scripts dependentes de register_globals mas que são seguros. Isso se inicializarmos as variáveis e validarmos os dados que são enviados pelo usuário.

Recomendações Finais

Como forma de resumir, podemos elencar algumas recomendações:

Mantenha register_globals = Off.: Se você tem acesso ao php.ini, altere a diretiva no próprio arquivo. Se não tem, faça sempre a alteração via .htaccess.
Mantenha a exibição de todos os tipos de erros.: Enquanto estiver desenvolvendo uma aplicação, mantenha a diretiva display_errors = On e error_reporting = E_ALL. Isso também pode ser feito diretamente no php.ini, através do .htaccess ou através da função ini_set, do PHP.
Valide todos os dados manupilados pelo usuário.: Sempre que você der chance de um usuário manipular dados nas suas aplicações (isso acontece a todo momento) seja por links, formulários ou cookies, faça a validação dos mesmos para ter certeza de que estão vindo de onde devem vir e com o valor de domínio.
Inicialize as variáveis.: Sempre inicialize as variáveis de formulário, links, etc.
Use empty e isset.: Lembre-se que o PHP tem funções poderosas e úteis, como empty e isset.

Neste artigo, vimos um assunto que deveria estar batido e mais do que impregnado na cabeça dos programadores PHP. Mas o que pode ser visto é que isto ainda não é uma realidade.

Penso que isso se deve pelo fato de que alguns livros famosos para aprendizado de PHP não abordam esses assuntos e, para facilitar a didática, explicam utilizando a dependência de register_globals.

Com a chegada do PHP 6 e a impossibilidade de estabelecer um valor (On ou Off) para register_globals, esse assunto torna-se ainda mais importante.

Peço que deixem seus comentários, dúvidas ou sugestões.

Até a próxima!

tmferreira

Referências

Usando a diretiva Register Globals

2 Comentários

Plugin jQuery para Contagem de Caracteres

Postado em Javascript por tmferreira em 30/07/2007

Fala pessoal!! Beleza?

Hoje precisei de um script para contar os caracteres restantes num campo de texto (textarea). Como não encontrei plugin do jQuery que faça isso, resolvi fazer um. :)

Este plugin é capaz de contar a quantidade de caracteres restantes para um textarea ou input text e exibir esta quantidade num local definido pelo desenvolvedor.

Eis as possibilidades de configuração:

max: define a quantidade máxima de caracteres. Se não for definido, busca o valor no atributo maxlength do elemento controlado.
mensagem: A mensagem que será exibida ao usuário. A mensagem padrão é “Restam $cont caracteres.”, onde $cont será substituído pela quantidade restante. $cont é obrigatório.
elemento: Tipo do elemento que será criado e receberá a mensagem descrita acima. Padrão: div.
elementoId: Valor do atributo id do elemento que será criado. Padrão: id_do_controlado + “_” + elemento.
elementoClasse: Valor do atributo class do elemento que será criado. Padrão: contador.
elementoInsert: Posição do elemento criado em relação ao elemento controlado. Aceita “antes” ou “depois”. Padrão: depois.

O Plugin Contador

Para mostrar a todos que sou muito criativo, escolhi o nome contador para este plugin. rsrsrsrsrs

Não colocarei o código aqui pois fica ilegível devido ao espaço disponível (largura). Mas vocês podem fazer o download aqui.

Formas de Uso

Para usar, realmente é muito simples para quem já está acostumado a utilizar o jQuery. Vejam:

Uso em Input Text

Da forma abaixo, será acrescentada a contagem em todos os elementos input que têm o atributo maxlength definido, utilizando as configurações padrão.
$("input[@maxlength]").contador();

Uso em Textarea

Para elementos textarea, precisamos necessariamente definir o valor da propriedade max, já que o textarea não tem o atributo maxlength.
$("textarea").contador({max: 200});

Uso Completo

Assim, demostro como modificar todos os valores padrão da função, deixando completamente customizável.
$("textarea").contador({ max: 200, mensagem: 'Você pode digitar $cont caracteres.', elemento: 'span', elementoId: 'caracteres_restantes', elementoClasse: '', elementoInsert: 'antes' });

Conclusão

Como puderam ver, não é tão complicado assim desenvolver um plugin do jQuery. Quem tiver curiosidade, pode dar uma olhada em como fazer um plugin seguindo este link.

Abraços a todos e até o próximo artigo!

tmferreira

0 Comentários

Próxima Página »

Quem é tmferreira?

Busque pelo Blog

Posts Relacionados

Links Patrocinados

Blogs e Links

Artigos e Posts

Categorias

RSS

Patrocínio

Anúncios Google

Como Fazer

Mas, por que a performance do front-end é importante?

Como é medida a performance de uma página?

Regras para Alta Performance

Conclusão

O Algoritmo Diffie-Hellman

Exemplo Prático

Descobrindo a Chave

Considerações

Conclusão

Introdução

Captcha

Testes de Lógica

Verificação por e-mail

Identificação por Documentos

Coleta de Perfil

Chat ou Telefone

Limitação de Utilização

Conclusão

Diretiva register_globals

Portabilidade

Segurança

Recomendações Finais

Referências

O Plugin Contador

Formas de Uso

Uso em Input Text

Uso em Textarea

Uso Completo

Conclusão