Os principais problemas s�o:
Performance:
O applet teria que carregar um grande n�mero de classes para trabalhar
com o BD, e abrir v�rias conex�es com o mesmo, para cada cliente que
estisse usando o sistema.
Portabilidade:
Este tipo de modelo � altamente dependente do browser do cliente, pois
toda a tarefa est� sendo realizada no applet. Com o modelo de Servlets
voc� tem total controle sobre a JVM que far� a tarefa no BD e pode
deixar apenas um formul�rio HTML para o cliente. Se utilizar uma
aplica��o a comunica��o poderia ser com sockets, como j� disse. Vale
lembrar que at� bem pouco tempo o RMI n�o era suportato pela IE.
Escalabilidade:
Seguindo a id�ia de cima, voc� pode escalar melhor sua aplica��o
deixando o seu cliente mais leve, com formul�rios HTML ou uma vers�o
simples de um applet. A tarefa de tratar os dados recebidos do servidor
poder� ser tratado pela aplica��o Server. Com isso vc pode at� mesmo
abrir uma �nica conex�o com o BD e utilizar threads para cada cliente.
Seguran�a:
Aqui vou colar a explica��o feita pelo Bruno em mensagem anterior. Uma
verdadeira aula:
Todas as linguagem sa "decompilaveis", inclusive (e especialmente)
Java. O maximo que voce pode fazer eh tornar as coisas um pouco
mais dificies, mas se voce tem apenas linhas do tipo:
String login = "username";
String senha = "senha123";
Voce nem precisa decompilar a aplicacao, basta uma rapida olhada
no binario, com qualquer "file viewer", para voce encontrar as
duas strings acima. Faca a experiencia.
Quanto a monitorar as informacoes, nao estou falando de alguem
monitorar as informacoes da sua maquina sem voce saber (isso pode
ser resolvido com criptografia), mas sim voce monitorar as
informacoes na sua propria maquina. Lembre-se, nesse caso (a
senha e o login sao os mesmos para todos), voce nao precisa
roubar a informacao de alguem, voce so precisa rouba-la
de voce mesmo.... Facil, nao?
Eh claro, voce pode fazer varias coisas para dificultar (Arthur,
aproveite essas dicas, que eu nao havia citado, ja que nao acho
que resolvam o problema, mas cabem nessa outra pergunta):
Voce pode criptografar o login/senha na sua aplicacao local, e
fazer com que a aplicacao descritografe no momento de usa-las.
Isso talvez obrigasse o "hacker" a entender a logica da sua
aplicacao, para poder pegar as informacoes, e ai sim ele precisaria
decompilar o seu codigo. Com um bom ofuscador de codigo, voce
tornaria dificil a compreensao do seu codigo, e dificultaria mais
um pouco o trabalho. Mas no fundo, se alguem quiser, ele vai
continuar capaz de entender o funcionamento da aplicacao e
capturar as informacoes.
No caso especifico da aplicacao do Arthur, ele nao tem controle do
applet da Oracle, e em algum momento, ele vai necessitar passar
essas informacoes para esse outro applet. Nesso momento, fica facil
capturar as informacoes. Se o Arthur fosse bem sofisticado, um
hacker de inteligencia mediana substituiria o applet da Oracle por
um applet proprio e receberia de bandeja os parametros. Mas nem
isso seria necessario. Qualquer um instalaria um analizador de
pacotes na propria maquina e esperaria que o applet que faz
o acesso a base de dados tentasse fazer a conexao, e tambem
receberia de graca os parametros de conexao do banco. Ah! voce
que enviar isso via SSL por exemplo? Tudo bem, eu instalo os
dois applets na minha maquina, copio o html, e faco o acesso
sem seguranca, na minha propria maquina. Ou seja, as possibilidade
sao muitas. E eu nem citei voce vasculhar a memoria do seu applet
esperando que a senha apareca em algum lugar.
Lembrem-se: podemos dificultar o trabalho, podemos impedir que
alguem interfira com as aplicacoes e informacoes de nosso usuario,
mas nao ha nada que se possa fazer se o nosso usuario quer roubar
suas proprias informacoes! O Applet esta RODANDO na maquina do
hacker, e as informacoes em questao sao UNICAS para todos os usuarios.
Basta o hacker "atacar" a si mesmo. Facil, facil. E depois, com
o login/senha, ele acessa a base de dados calmamente.
Moral da historia: seguranca eh um assunto complexo. Nao adianta
tentar ser mirabolante quando a arquitetura esta furada, ou como
diz o jargao: "Nao adianta colocar portas de ferro em cabanas de
palha". Nesse caso, o erro eh o applet fazer o acesso aa base de dados
diretamente. Por isso na minha primeira resposta, a minha proposta
foi a de se fazer uma arquitetura mais segura (e, de lambuja, melhor
a longo prazo.)
Reveja os e-mails com o subject "about Help me" postadas aqui na lista.
Um forte abra�o.
Handerson F. Gomes
Otavio Fernandes Fontenelle wrote:
>
> Obrigado, Handerson, Bruno, pelos esclarecimentos.
>
> Soh para concluir nosso pate-papo. Por que que eh tao indesejavel colocar
> a logica (conexao etc e tal) do BD na applet cliente? Seguranca?
> Performace?
>
> Abraco a todos.
> ___________________________________________________________________________
> OTAVIO FERNANDES FONTENELLE E-MAIL :[EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Centro Nacional de Processamento Campus do Pici - Bloco 901
> de Alto Desempenho no Nordeste CEP: 60.455-760
> (CENAPAD-NE) Tel.: +55 085 287-5044
> Fax: +55 085 288-9985
>
> Fortaleza - Ceara - Brasil
> ___________________________________________________________________________
>
> * Para nao receber mais e-mails da lista, acesse
><http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha
>a lista <[EMAIL PROTECTED]> e de um <submit>.
* Para nao receber mais e-mails da lista, acesse
<http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha a
lista <[EMAIL PROTECTED]> e de um <submit>.
