Autenticação e Autorização: JAAS com JDBC Realm

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

  • Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
  • Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

Continue reading

A sabedoria numa corrida de canoas

Essa semana recebi uma historinha muito interessante por e-mail e que talvez, muitos já a conheçam. Mas eu nunca havia lido antes, então vou fazer um resumo da história da “Corrida de Canoas” que é uma adaptação para o cotidiano de muitas empresas de desenvolvimento de software, infelizmente. O caso em si é um clássico, semelhante a outro que postei aqui no blog há um tempão, mas que nos remete a reflexões que deveríamos ter por pelo menos alguns instantes diários, mas que no corre-corre deixamos passar.

Nota: Esta história, assim como milhares de histórias que recebemos por e-mail todos os dias, não tem um autor oficial, ou tem um “novo” autor a cada semana ou uma versão diferente ou uma adaptação diferente. Numa rápida pesquisa no google eu encontrei dezenas de variações da história e principalmente do autor, então como eu não sei quem é o autor verdadeiro e como no e-mail que eu recebi também não havia citação para o autor, deixarei sem referências, mas que fique claro que se alguém souber o autor verdadeiro pode dizer que eu atualizarei o post com as referências.

A história: A Corrida de Canoas

corrida_canoa_01Duas empresas (de acordo com a história, uma brasileira e outra japonesa) criaram um desafio que consistia numa corrida anual de canoas, onde, em cada canoa iriam até 8 homens de cada empresa.

Então as equipes treinaram arduamente e estavam em sua melhor forma no dia da corrida. No entanto, os japoneses venceram com mais de 1km de vantagem.

Após a grande derrota a equipe brasileira ficou muito desanimada e chegou a pensar em desistir, mas o diretor geral da empresa brasileira decidiu que venceriam no próximo ano e, para tal, criou um grupo de trabalho para examinar o que houve de errado na corrida.

Depois de muito tempo de estudos, análises e relatórios, o grupo que examinava os fatos da corrida concluiu que a equipe japonesa possuía em seu barco um capitão e sete remadores enquanto a equipe brasileira possuía sete capitães e um único remador. O diretor geral tomou uma decisão e contratou uma terceira empresa para analisar a estrutura de sua equipe.

corrida_canoa_02Depois de longos meses de trabalho os especialistas contratados concluíram que a equipe possuía capitães de mais e remadores de menos, e informou isso ao diretor geral. Este, por sua vez, decidiu então que a estrutura da equipe deveria ser alterada imediatamente.

A estrutura da equipe foi então reformulada e ao invés de sete capitães, teria agora apenas 4 capitães, dois supervisores de capitães, um chefe de supervisores e um remador. Mas agora o remador teria atenção especial, toda a equipe funcionaria a seu favor, o remador deveria ser melhor qualificado, ter mais treinamento, ser constantemente motivado e principalmente ser conscientizado de sua inviável responsabilidade.

Chegou o próximo ano e ao final da corrida a equipe japonesa venceu mais uma vez, porém com mais de 2km de vantagem, o dobro da vantagem do primeiro ano de corrida.

corrida_canoa_031O diretor geral em conjunto com toda a diretoria da empresa brasileira decidiu que o remador deveria ser demitido pelo seu péssimo desempenho na corrida. E decidiram também, que para não desmotivar o resto da equipe todos seriam recompensados com um prêmio por sua enorme dedicação e motivação que tentaram, sem sucesso, incutir na equipe.

O diretor geral preparou um relatório da situação, no qual ficou demonstrado que: A melhor tática havia sido escolhida, a equipe estava bem organizada e que havia motivação suficiente mas que o material utilizado ainda deveria ser melhorado e, por último, que um remador mais qualificado e empenhado deveria ser contratado.

Hoje a empresa está cogitando a idéia de trocar ou construir uma nova e mais moderna canoa.

Fim da história! =D

Apesar de parecer engraçado, esse cenário é, na verdade, trágico quando acontece na vida real. Não é difícil encontrarmos situações como essa em nosso dia-a-dia. Aqui no Espírito Santo costumamos dizer essa é uma situação onde temos muitos caciques para poucos índios.

Muitas boas conclusões podem ser tiradas dessa história: os muitos caciques para os poucos índios, inabilidade para detectar a causa raiz de um problema, agir onde não está a causa problema, superestimar os problemas (vide o grupo para analisar a corrida e em seguida os consultores especialistas) e principalmente, foco no processo e não nas pessoas.

Maven ‘mvn release:prepare’ falhando com SVN

Um problema com a geração de releases com o maven tem incomodado muita gente nas últimas semanas. Trata-se de alguma incompatibilidade entre o maven e os clientes de SVN de versão superior a 1.5.x. O problema ocorre na preparação da release (mvn release:prepare) e diz que o pom.xml já existe no diretório da tag que nem foi criada ainda.

Existe uma solução bem simples que deverá funcionar de primeira caso seu ambiente de desenvolvimento seja *nix que é basicamente executar um update na sua working copy antes de preparar a release:

svn up -r head
mvn release:prepare

Entretanto, se você não tem vergonha na cara e desenvolve no windows o procedimento é um pouco mais chatinho, vejamos:

mvn release:prepare
## vai dar erro, continue
svn up -r head
mvn release:prepare -Dresume

E se você tiver o TortoiseSVN instalado mate o processo TSVNCache.exe antes de executar os passos acima.

Há esperanças de que a versão 1.5.5 do SVN Client dê um fim nesse problema, mas enquanto ela não chega temos que nos contentar com essa gambiarra terrível. Provavelmente este procedimento deverá ser executado no release:perform também.

Porque eu não compraria o IntelliJ IDEA

Não é nenhum segredo que eu gosto muito do Eclipse, já andei falando isso aqui no blog por algumas vezes. Também já fiz um retrospecto de como foi uma experiência trabalhando com Netbeans, a qual resultou numa migração para o Eclipse. Desta vez a experiência está sendo com alguns produtos da JetBrains, e como andei falando muito bem do TeamCity, muita gente já me pertubou dizendo que eu fui muito parcial, então agora vou falar um pouco sobre o Intellij IDEA, versão 7.

Eu tenho no meu computador pessoal o Intellij IDEA 8 devidamente licenciado e registrado graças a um programa da Jetbrains que presenteia JUG Learders com licenças de seus produtos. Apesar disso eu nunca dei tanta atenção a esta ferramenta além de um projetinho de brincadeira aqui ou outro ali.

Mas ultimamente estou trabalhando numa equipe onde o Intellij IDEA 7 é a IDE oficial, até então nada de mais, eu pensei: “Vou usar o Eclipse, não tem problema”. Mas esta equipe possui uma certa proximidade com a ferramenta e possuem até plugins desenvolvidos para o IDEA que facilitam o trabalho com os produtos criados e mantidos pela empresa. Então aproveitei para não criar mais empecilhos e topei a experiência.

Já li e ouvi comentários fervorosos sobre o IDEA, pessoas que realmente gostam muito desta ferramenta. Na maioria das vezes sempre elogiam: o editor, as formas diferentes de code completion que podem ser alteradas ao gosto do desenvolvedor, as opções de refactoring, dentre algumas outras.

O primeiro: suporte a code completion. Não achei que fosse um diferencial que pudesse justificar o preço a ser pago na ferramenta. Existem alguns recursos interessantes nesta parte, é fato. Por exemplo poder controlar se o case sensitive será aplicado somente na primeira letra do que estiver sendo digitado, em todas elas ou em nenhuma. Excluir determinados pacotes/classes/métodos do code completion eu também gostei.

No editor, o recurso como ele chama de Virtual Space eu não gostei nem de longe, basicamente o editor permite que o cursor possa ficar em qualquer lugar, mesmo dentro de um espaço de tabulação ou após o final da linha, ou seja, espaços que não existem – virtuais. Este recurso pode ser desabilitado, mas vem ativado por default e eu perdi uns bons dias para descobrir que podia ser desabilitado. Da mesma forma o limite de abas abertas, além de ser pequeno (por default, somente 10) ele não avisa que chegou no limite, simplesmente funciona como uma fila, os mais antigos são descartados em detrimento aos mais novos. Poder abrir os arquivos com apenas um clique também é legal, mas não ter um botão pra fechar a aba e ter que usar o botão direito pra isso não é muito legal.

As opções de refactory são boas, mas ainda sinto um pouco de dificuldade com os nomes diferentes, geralmente onde eu esperava encontrar um “Extract Method”, por exemplo, acabo encontrando um “Introduce Method”. Só que ainda não encontrei “Aquela” opção única de refactory que só exista no IDEA e que fosse muito boa.

Aproveitando que foi o post sobre TeamCity que me fez escrever este post, o plugin de integração entre o IDEA e o TeamCity é legal, mas o melhor recurso que o plugin trás, o Delayed Commit, também pode ser usado com o plugin para Eclipse ou Visual Studio, então, menos um ponto para se prender a uma IDE paga.

A comunidade desenvolvedora de plugins não me pareceu tão grande e ativa quanto a do Eclipse, e isso, pra mim é um grande diferencial. Considero e dou muito mais valor ao “suporte” da comunidade e das pessoas que lidam diariamente com uma ferramenta do que aquele suporte que você compra e paga.

Estou usando o IntelliJ IDEA há cerca de 6 ou 7 semanas, então eu posso ainda não ter descoberto as “maravilhas” que o façam valer o seu preço, mas enquanto não encontrei e ninguém da equipe me mostrou tais maravilhas, continuo pensando que não vale a pena devido ao preço e à altertivas como o Eclipse. Não considero o IntelliJ IDEA uma ferramenta ruim, apenas considero uma estratégia ruim uma empresa gastar seiscentos doláres por licensa numa ferramenta que, ao meu ver, não irá agregar um diferencial que justifique o seu preço.

Integração contínua é com TeamCity

Recentemente fui convidado a montar o ambiente de integração contínua de uma empresa. O trabalho inicial de verificação dos projetos, testes e builds existente foi feito como manda o figurino. Todos os projetos usavam maven2 e, felizmente, todos eles (inclusive os sub-projetos) possuíam pom’s bem configurados e completamente funcionais.

Os builds e processos internos (manuais) para builds da empresa estavam ok, verificados e funcionando. Feito isso fomos aos testes. Testes!? Ok, vamos ao próximo passo e esqueça os testes por enquanto. O controle de versão era feito com Subversion e os clientes usando Tortoise. A IDE utilizada por toda a organização era o IntelliJ IDEA, mesmo assim o cliente para o SVN era o Tortoise, ainda tento compreender isso até hoje.

wheresthebuild-smallA empresa estava em um momento de criação e manutenção de testes funcionais, então, algumas pessoas estavam trabalhando exclusivamente com Selenium. Era uma boa oportunidade, pois estes testes seriam todos automatizados no ambiente de integração contínua a ser preparado. Uma série de procedimentos foram realizados até chegarmos no ambiente de facto, mas vou pular isso para o post não ficar grande e chato de mais.

Comecei então com a preparação de alguns protótipos. Já trabalhei algumas vezes em ambientes de integração contínua com o CruiseControl e também com o CruiseControl.rb, logo pensei em utilizar um desses. Pesquisando e perguntando a conhecidos cheguei às indicações de: Hudson com muitas indicações, Continuum da Apache, TeamCity da JetBrains e Bamboo da Atlassian, sendo estes dois últimos privados e com custo para licença. Ainda assim estava considerando as duas alternativas pagas logo depois de alguma alternativa da família CC, isto porque a empresa possuía licenças do Jira e Confluence, logo o Bamboo poderia ser uma boa pedida devido a recursos de integração. E também possuíam licenças do IntelliJ IDEA, logo a integração com a IDE poderia ser um ponto positivo para o TeamCity.

Alguma coisa aconteceu comigo e na manhã seguinte eu resolvi começar pelas ferramentas que eu não conhecia. Comecei pelo Hudson, TeamCity e por último Continuum, resolvi parar por aqui pra não perder mais tempo, nesse momento já havia uma escolha muito clara e três dias já haviam se passado.

Continue reading