quarta-feira, 31 de agosto de 2011

Desenvolvimento PHP no mundo real

Esse post tem o objetivo de mostrar o dia-a-dia de um desenvolvedor com uma nova línguagem e amedrontar os estudantes e possíveis estudantes na área de sistemas.

Veja a lista de problemas que tivemos na Evodata em um único projeto PHP.

Instalamos o WAMP, baixamos o NetBeans 7 (muito bom pra PHP e Javascript, integra legal com o jQuery), as bibilhotecas jQuery, jQuery UI e beleza.

Fizemos as primeiras telas do sistema, apresentamos ao cliente, ele gostou e pediu para colocarmos em um servidor dele para ele poder apresentar ao cliente dele.

Descobrimos primeiro que o servidor utilizado pelo nosso cliente estava configurado com opções não recomendadas, o pior foi o bendito REGISTER_GLOBALS, ele mistura variáveis globais com os atributos da SESSION os parametros GET e POST do PHP.

Explicando melhor o problema 1)

A sessão tinha uma variavel idioma (que grava o id do idioma do usuário logado), quando um usuário admin  cadastrava um usuário (que tinha um campo idioma que era enviado via post no formulário) o idioma da sessão se tornava o idioma do usuário recém cadastrado.

Resolver é fácil, desligue o REGISTER_GLOBALS, mas o cliente tinha uma hospedagem windows na locaweb e ele usa outros sistemas em ASP e ASP.net (a locaweb não deixa desligar o REGISTER_GLOBALS na hospedagem windows)

Com a fase inicial funcionando, passamos as novas funcionalidades do sistema, fizemos testamos e apresentamos ao cliente.

Ele novamente aprovou, e fomos subir no servidor dele novamente e adivinhe, a versão do PHP do servidor era bem antiga e não suportava comandos como o __DIR__ que haviamos usado.

Como o cliente queria muito o sistema dele no ar ele decidiu por comprar um serviço de cloud server na propria locaweb.

Ele veio com um linux beeem estranho, e foi um parto conseguir instalar todos os pacotes nele, por sorte essa parte de infra-estrutura era por parte do cliente, mas o TI dele passou alguns dias até deixar o ambiente ok.

Até que enfim subimos o sistema no servidor novo e adivinhem! Novo problema, as tabelas estavam com nome minusculo mas nossas SQL's estavam referenciando elas em upcase.

No windows isso não faz diferença (da para configurar para ser case-sensitive, mas não é o padrão), já no Linux o padrão é case-sensitive.

Alteramos todos os nomes de todas as 60 tabelas do sistema para upcase e sistema rodando.

Como antes de PHP desenvolviamos em Java, estavamos acostumados a usar parametros com placeholders como o "?", usado pelo JDBC, nossa sorte é que o PDO tem um esquema similar e usamos isto em todas as funções de banco.

Isso além de deixar as coisas um pouco mais separadas, ajuda a proteger o sistema contra SQL-Injection, então esse foi um ponto muito positivo.

Desde o começo do projeto tivemos dúvidas sobre segurança, sabiamos que usando os bindParam e bindValue estavamos protegidos contra SQL-Injection, mas isso é tudo?

Foi ai que nos deparamos com o XSS, pesquisamos e testamos várias técnicas de combate ao XSS e achamos a função htmlspecialchars(), que transforma as tags como <> em &lt; e &gt; e o

Isso faz com que se alguem tentar colocar um código javascript dentro de um form do seu sistema, ele será escapado e mostrado como texto.

E depois veio roubo de id da sessão e por assim vai...

Fato é, você só aprende a desenvolver desenvolvendo.

quinta-feira, 25 de agosto de 2011

APIs livres em softwares comercializados quais licenças usar

No dia-a-dia da Evodata Sistemas temos que escolher se vamos desenvolver algo, ou se vamos procurar algo pronto.
Uma opção é comprar components, mas as vezes o preço não compensa, ou como é algo pago e menos usado é dificil achar informação em fórums.

Então sempre que possivel utilizamos componentes e frameworks de código livre.
Porém nem todo codigo livre pode ser usado em produtos comerciais, boa parte só pode ser usada para uso próprio (pessoal) ou para compor software que também seja livre.
Então depois de uma pesquisa definimos que é seguro usar em aplicações comerciais as seguintes licenças:

LGPL: Lesser GPL, permite o uso em softwares GPL e softwares comerciais.
Licença MIT: Permite uso em sistemas livres e comerciais.
Eclipse Public Licence EPL: Permite o uso em softwares comerciais, des de que não se altere o framework (no caso de alteração, só a parte alterada deve ser obrigatóriamente licenciada em EPL, o resto do sistema pode ser comercial).
Licença Apache: Permite uso e inclusão dos fontes em sistemas comerciais.
CDDL (netbeans): Assim como a EPL permite uso em softwares comerciais, mas alterações no core devem ser devolvidas a comunidade com licença CDDL.

Muitas empresas as vezes por falta de conhecimento ou falta de tempo para avaliar as licenças dos frameworks acabam por usar inadvertidamente frameworks sob licença GPL para sistemas proprietários, o que é crime de quebra de direitos autorais contra a pessoa ou organização que criou o framework e licenciou como GPL.