>
> Bruno,
>
> valeu a aten��o!
> Agora ... acho que c entendeu o come�o, pegou outro caminho no meio
> disparou no atalho e acabou em algum lugar ... eu n�o sei onde mas com certeza
>
> loge da TERRA. : )
Na verdade, so mostrei a grande angular, para voce saber onde voce
deve ir...
> � um prazer receber um email seu - tive oportunidade de ir a uma palestra sua
> aqui no Cear� (UFC) e desde l� Java � uma paix�o por�m platonica.
> S� agora comprei aquela canequinha que voc� fez inveja e n�o sorteou pra
> ninguem!
> Mas papo a parte ... amigo deixa eu tentar te explicar melhor:
>
> 1 - o applet que faz negocia��o com o BD � d� Oracle veio no cd de instala��o
> do Forms;
> 2 - a Oracle n�o abre c�digo - no caso de apenas trocar o parametro a receber
> e recompilar como se fosse uma vari�vel interna, evitando passar pela chamada
> da applet.
> 3 - o login e senha s�o �nicos para todos que forem acessar este servi�o, ou
> seja,
> quem chegar a esta p�gina HTML que chamar� a applet j� passa por uma iden-
> tifica��o, mas mesmo estes usu�rios n�o podem saber o login e senha do BD pois
>
> al�m deste login e senha possu�rem aplica��es restritas eu quero evitar que o
> cara
> pegue um acess da vida e monte um mini-BD onde ele entra, s�i sem um controle
> de negocia��o meu.
> 4 - a id�ia � criar uma applet que apenas fa�a a tal applet da Oracle rodar
> e sendo assim os parametros estariam secondidos sobre a forma de byte-code.
> Isto �, toda a chamada estaria compilada (n�o vis�vel) ao usu�rio.
>
>
Eu entendi perfeitamente. A sua primeira pergunta, apesar de nao dar
os detalhes de base de dados, do forms, etc, estava perfeitamente
clara, ja que as arquiteturas nao variam muito, e so existe algumas
formas basicas de se fazer a mesma coisa, so que umas sao melhores que
outras, e o que eu te mostrei eh melhor do que o que voce propoe...
O problema (de novo) eh que esta tudo errado. Voce esconder os
parametros de login/senha no codigo do seu applet tem _o mesmo efeito_
de voce deixa-los aberto no HTML.
Ou seja, quem nao sabe nem tem interesse de acessar o seu banco de
dados, nao vai nem ligar para o fato de ter o login/senha no HTML.
Por outro lado, quem quiser burlar a sua "seguranca", e souber fazer o
acesso ao seu banco de dados (via o "mini-BD" que voce sugeriu), nao
tera a menor dificuldade em pegar o login/senha, esteja isso visivel
no HTML, esteja compilado no codigo do seu applet. Qualquer um, mesmo
sem um decompilador, encontraria facilmente essas informacoes nos
bytecodes do seu applet. Ainda que nao encontrasse, ele facilmente
encontraria essas informacoes ao monitorar as informacoes que
passam na rede, entre seu applet e o banco de dados. Qualquer um
medianamente esperto eh capaz de fazer isso. E se nao for capaz,
basta baixar um software da rede e pronto....
Moral da historia: se voce vai enviar o seu login/senha atraves
do seu applet, nao vale a pena criar coisas mirabolantes, ja que
essas nao trarao o menor resultado. A saida eh voce repensar a sua
aplicacao, e foi essa a minha proposta. Na verdade, quando voce
esta falando de internet, voce sempre deve pensar na sua aplicacao
mais ou menos nos termos que escrevi. Na verdade o que eu coloquei
nao eh nada longe da terra, muito pelo contrario, eh um caminho
inteligente e logico para o crescimento nao apenas da sua aplicacao
(qualquer que seja ela), mas tambem para o seu crescimento
profissional.
Agora, se o seu problema reside no fato de voce estar usando um
codigo de um fornecedor qualquer, eu sugiro voce a procurar junto a
esse fornecedor qual a solucao proposta por eles. No caso que voce
citou, acredito que o applet fornecido visa o acesso intranet, e nao
o acesso internet. As solucoes internet necessariamente serao
diferentes.
Lembre-se essa eh uma das grandes vantagens de Java: se o fornecedor
que voce esta usando apresenta uma arquitetura pobre e ineficiente,
procure outro! Use a liberdade que a tecnologia Java te fornece.
Ou entao, se contente com o que voce tem. O fato eh que no aspecto
seguranca, enviar o login/senha pela rede como voce propoe esta furado,
de um jeito ou de outro. E o pior eh que arquiteturalmente, essa
solucao (um applet que acessa um banco de dados diretamente) eh
horrivel, se voce estiver considerando a Internet.
A forma mais facil eh manter tudo no HTML, e, na hora de aceitar
a inscricao, fazer com que a pessoa assine/aceite um contrato que
diz: QUEM TENTAR ACESSAR MINHA BASE DE DADOS SEM PASSAR PELO MEU
APPLET SERA PROCESSADO. Depois disso, espere pelo melhor, mas
que seus dados estao em risco, isso estao.
>
> Arthur. N�o perca as esperan�as, Help me please!
Espero que voce nao perca as esperancas :o) Espero que agora
tenha ficado mais clara a minha resposta.
Abracos,
Bruno.
>
> Bruno Souza - Sun do Brasil wrote:
>
> > Se isso eh por questoes de seguranca, esta tudo errado desde o
> > principio....
> >
> > Login/Senha dentro do codigo do seu applet sao tao visiveis como no
> > HTML (na verdade, para pessoas leigas sao invisiveis, mas para pessoas
> > leigas, o HTML tambem eh invisivel...)
> >
> > Se seu problema de seguranca eh tao insignificante que voce acha que
> > alguem interessado nao tentaria descobrir o login/senha dentro do
> > applet, entao voce pode coloca-lo no HTML sem maiores problemas.
> >
> > Agora, tentando entender o seu problema _real_: vamos ver, porque
> > voce esta querendo enviar o login/senha dentro do codigo do applet?
> > Voce citou "Oracle" no seu e-mail, portanto tem uma base de dados na
> > jogada, e provavelmente voce esta fazendo um applet que acessa direto
> > a sua base de dados (provavelmente via JDBC), e voce esta enviando no
> > codigo html o login/senha do seu banco de dados. Voce esta preocupado
> > com o fato que alguem possa entao acessar a sua base de dados e fazer
> > estragos.
> >
> > Como primeiro comentario, em geral uma aplicacao cliente/servidor
> > tradicional (i.e.: toda a logica no cliente + BD como servidor) nao
> > funciona muito bem na web, e entre outro problemas esta a questao de
> > que voce precisa dar acesso aa sua base de dados para qualquer usuario
> > web. Ou seja, qualquer um com um minimo de conhecimento, pode acessar
> > a sua base de dados para fazer outras coisas, nao necessariamente o
> > que voce programou no seu applet. Isso por si so ja eh arriscado, e
> > como voce precisa enviar o login/senha para qualquer um, fica mais
> > facil ainda.
> >
> > A solucao para isso? NAO PERMITA acesso a sua base de dados
> > diretamente!!! Escreva algum codigo (ou use um servidor de
> > aplicacoes, ou um middle tier qualquer), e faca o acesso ao seu banco
> > de dados A PARTIR DO SEU SERVIDOR! O seu applet so pode se conectar a
> > esse servidor (que tal usar o RMI para fazer isso? Simples e facil),
> > e eh o servidor que envia a query para o banco de dados. Voce nao
> > precisa distribuir na rede o seu login/senha, e voce nao permite
> > acesso ao BD por qualquer aventureiro. Alem de tudo, essa solucao eh
> > muito mais condizente com a web, e permite, se voce quiser, rodar
> > parte da logica no servidor, e fazer seu applet menor e mais rapido.
> >
> > Se voce pensar um pouco mais, voce pode ter a logica rodando em um
> > servlet, e esse servlet acessa o seu servidor (que voce ja fez no
> > paragrafo anterior), tambem via RMI, e voce agora tem tanto um cliente
> > Java, como um cliente HTML, fazendo o mesmo acesso a sua base de
> > dados. Agora a coisa esta ficando com cara de internet....
> >
> > Se voce seguir nessa linha, seus proximos passos sao transformar o
> > seu servidor (isso, aquele desenvolvido a dois paragrafos atras), e
> > transforma-lo em componentes, e transforma-lo em Enterprise JavaBeans,
> > e voce passa a poder disponibiliza-lo em varios servidores de aplicacao
> > do mercado, ganhando vantagens como escalabilidade, load-balancing,
> > alta disponibilidade, seguranaca, etc. Agora voce esta pronto para
> > que milhares de usuarios acessem seu sistema.
> >
> > Se voce chegou ate aqui, eu sugiro que voce de uma rapida olhada
> > no Jini, e com algumas linhas de codigo, transforme os seus EJBs
> > em Jini-enabled, e voce podera coloca-los aa disposicao de qualquer
> > cliente na rede, como servicos Jini. Isso abrira as portas para
> > uma serie de servicos interessantes e sua aplicacao pode pegar a
> > concerrencia desprevinida.
> >
> > Agora, se voce nao quer desenvolver para o futuro, e nao pretende
> > ter uma aplicacao verdadeiramente de rede, pode mandar o login/senha
> > direto no HTML. Em questoes de seguranca, nao vai fazer diferenca.
> >
> > Outra opcao eh criar o login como: hg4wks56: e a senha como 77tya!lwd
> > e nenhum usuario (leigo) vai saber o que isso significa, vai ficar
> > parecendo criptografia, e voce estara seguro. Se isso vai enganar
> > os usuarios espertos e capazes de causar dano? Claro que nao, mas
> > tudo bem, esconder no codigo do Applet tambem nao vai engana-los, e
> > isso eh mais simples de fazer...
> >
> > Desculpe o e-mail longo. Espero ter conseguido mostrar a ideia...
> >
> > (PS: para quem nao entendeu nada: va para http://java.sun.com/products
> > e estude Java, JavaBeans, RMI, Servlets, EJB, Jini. Nessa ordem.
> > Depois pode reler o e-mail, vai ficar mais claro :o)
> >
> > Abracos,
> >
> > Bruno.
> > ______________________________________________________________________
> > Bruno Peres Ferreira de Souza Sun Microsystems
> > System Engineer - Java Technologist [EMAIL PROTECTED]
> > if I fail, if I succeed, at least I live as I believe
> >
> >
Bruno.
______________________________________________________________________
Bruno Peres Ferreira de Souza Sun Microsystems
System Engineer - Java Technologist [EMAIL PROTECTED]
if I fail, if I succeed, at least I live as I believe
* 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>.
