Seguinte, achei uma coisa agora que simplesmente inviabiliza o uso do JPA para produção.
Ao extrair o .jar gerado pelo netbeans e navegar pelas pastas extraidas chego ao persistance.xml e la dentro para minha surpresa esta os dados de conexão sem nenhuma dificuldade.
Tá beleza, é meu tcc e teoricamente não há problemas, agora imagina um software para uma empresa onde qualquer funcionário com acesso ao .jar consegue os dados de acesso ao sistema?
Como corrigir?
Os famosos ByteCodes “escondem” meu código fonte, mas e xml da persistencia? Tem que ficar aberto mesmo?
As implementações de JPA nos application servers comerciais (WebSphere, Weblogic, etc.) normalmente deixam a senha em um outro arquivo, gerado na interface de administração Web, justamente por causa disso. Esse arquivo pode ser protegido com permissões de acesso mais restritas.
De qualquer maneira, normalmente você bota o servidor de banco de dados de produção em um lugar protegido por um firewall de modo que só a máquina que tem o servidor de aplicações, e mais as máquinas dos administradores de bancos de dados de produção, podem acessá-lo. Dessa forma, você não precisa se preocupar em senhas, já que você nem pode ver o servidor
Mas e em aplicações Desktop? JPA não é recomendado então para aplicações assim? Porque a senha está lá no XML pra quem quiser ver
No brasil, principalmente no interior, conexão estável com a internet ainda é um problema, e nem todas empresas querem investir em um bom servidor para rodar as aplicações. Ou seja, ainda utilizam o velho e bom aplicativos desktop;
De qualquer maneira, em uma aplicação Desktop, os arquivos não precisam ficar “abertos” - podem ficar dentro do jar mesmo . A senha do banco pode ficar em aberto ou não que não vai fazer diferença nenhuma, já que os dados não são criptografados no banco. Você pode, com alguma paciência, mexer em dados de qualquer banco, se tiver os arquivos do banco disponíveis, sem saber a senha
Mas se eu tenho os dados de acesso ao bd por exemplo eu posso ir lá e “brincar” de inserts, updates e deletes, isso nas mãos de alguém mal intencionado é um perigo.
Pois bem, é questão de você olhar a documentação da sua implementação específica de JPA.
Pode ser que já haja algum suporte a criptografar essa senha, ou deixá-la em outro arquivo que possa ficar no JAR.
Você não é o primeiro cara que reparou nessa tal “vulnerabilidade”.
Tem alguma forma então de (sem eu ter que reescrever o que já esta pronto) eu passar a carregar isto através da Web? Tipo algum servidor web apache que carregue o meu JAR dentro do navegador sem enviar o JAR diretamente para o cliente?
Você pode criar um aplicativo Swing que acessa EJBs em um servidor de aplicação cuja senha do banco está apenas lá. O JBoss e o Weblogic, por exemplo, deixam você manter a senha criptografada na definição dos datasources.
O JPA não revela a senha do banco. Quem revela é a pessoa que toma péssimas decisões arquiteturais.
Mas e então? Alguem ai sabe me dizer se tem algum Applet que execute JAR? Ou um servidor java (linux ou windows) que execute o jar e envie as respostas ao usuário sem ser jsp? Seria tipo um RemoteApp do Windows + Remote Desktop