Duvida sobre applet

Tenho um sistema que sempre chamou uma applet normalmente, fiz uma modificação no código desta applet e agora ele me pede uma assinatura do applet!
Alguem sabe pq que antes eu não precisava gerar essa assinatura agora eu preciso???´Será que depende das classes que eu uso no código da minha applet??

Existe 2 tipos de applet:
1-SEGURAS - são assinadas com certificado digital…assim vc tem 100% de certeza de saber a procedência. As applet assinadas tem liberdade total de execução na estação do usuário, uma vez q são aplicações desktops.
2-NÂO SEGURA - não são assinadas e não tem como garantir sua procedência. Applet não assinadas rodam numa SAND BOX no qual não podem executar uma serie de situação evitando código maliciosos.
Veja - http://docs.oracle.com/javase/tutorial/deployment/applet/security.html

Qualquer duvida leia um tutorial

• http://docs.oracle.com/javase/tutorial/deployment/applet/

vlw Fernando

achei um método na internet que seta uma propriedade do sistema como null, acho q isso não é correto fazer segue o metodo:

System.setSecurityManager(null);

setando esse código o erro parou!!!
vcs sabem o que isso pode ocasionar ??? fica sem segurança para acessar internet??? ou tem mais algum risco???

vlwwww

Tenho a mesma duvida… do amigo acima…

Alguem sabe???

De acordo com o trecho do código que peguei na classe System aparentemene nada acontece, simplismente retorna null…
Mas a duvida fica… isso pode refletir em algum outro lugar?

/**
     * Sets the System security.
     *
     * <p> If there is a security manager already installed, this method first
     * calls the security manager's <code>checkPermission</code> method
     * with a <code>RuntimePermission("setSecurityManager")</code>
     * permission to ensure it's ok to replace the existing
     * security manager.
     * This may result in throwing a <code>SecurityException</code>.
     *
     * <p> Otherwise, the argument is established as the current
     * security manager. If the argument is <code>null</code> and no
     * security manager has been established, then no action is taken and
     * the method simply returns.
     *
     * @param      s   the security manager.
     * @exception  SecurityException  if the security manager has already
     *             been set and its <code>checkPermission</code> method
     *             doesn't allow it to be replaced.
     * @see #getSecurityManager
     * @see SecurityManager#checkPermission
     * @see java.lang.RuntimePermission
     */
    public static
    void setSecurityManager(final SecurityManager s) {
        try {
            s.checkPackageAccess("java.lang");
        } catch (Exception e) {
            // no-op
        }
        setSecurityManager0(s);
    }

remove todo o contexto de segurança do “sandbox da JVM” e não deve ser usando em produção…ninguém aceitaria um recurso assim…
Me desculpe mas vc ta resolvendo um problema adicionando outros, sem compreender o contexto da coisa…
Vc precisa entender o contexto para resolver o problema…

Boa tarde a todos.

Existe uma questão sobre applets que deve ser comentada:

Por razões de segurança, geralmente é considerado perigoso permitir que applets ou qualquer outro programa que você executa a partir de um navegador Web acessem seu computador local (Cliente). Você deve decidir se confia na fonte (Provedor) ou não de onde você o está requisitando. Por exemplo: se você optar em fazer um download de uma nova versão do navegador Firefox, você irá baixá-lo no site do Mozilla, neste caso você obviamente confiará no site do Mozilla, eis que estar te interessando no momento é o produto final que é a nova versão do navegador Firefox, e a confiança será tanta que você não levará em conta que o programa baixado fará modificações nos recursos do seu sistema, acrescentar novas bibliotecas, alterar o registro do windows, entre outros, ainda que de forma bem intensionada.

Assim como todo programa, as applets eram totalmente descarregadas no computador local, antes de serem executadas e tão logo acabavam de serem descarregadas, eram automaticamente executadas, sem que houvesse algum programa verificador, um anti-vírus qualquer ou até mesmo um usuário fosse autenticado, e ai que morava o perigo, pois applets já foram criadas até para instalarem cavalos de troia. Diante deste fato, os projetistas do java na Sun-microsystems se sensibilizaram e criaram um sistema de segurança de applets, o qual o chamaram de “Modelo de Segurança de Caixa de Areia - The Sandbox Model em inglês”. A origem do nome se prende ao fato de que tal sistema faz com que as applets ao serem executadas, seja monitoradas por um gerenciador de segurança chamado Applet Security Manager - Gerenciador de Segurança de Applet, que lança uma interrupção do tipo SecurityException, caso a applet viole qualquer regra de segurança imposta, e a idéia de caixa de areia surgiu de que elas servem para amortecer qualquer impacto de um desastre.

As tarefas que as applets podem executar sem nenhum tipo de restrição, são: exibir imagens, executar sons, processar o acionamento do teclado, do mouse e se comunicar com o computador host de onde foram carregadas. Por outro lado, applets não podem executar programas localmente instalados, não podem se comunicar com outros hosts exceto de onde ela foi carregada, não podem ler e escrever no sistema de arquivos local, não podem escrever nada no host de onde foi carregada e não podem obter informações do sistema em que operam, exceto sobre a JVM, e isto pode causar um outro inconveniente que é a restrição de gravação de dados no Servidor (host) de um arquivo de imagem de uma webcam, por exemplo.

Inicialmente voce deve ter programado a sua Applet com instruções sem nenhum tipo de restrição, porém ao adicionar qualquer comando de acesso de arquivo no cliente, ai a Applet exigiu a assinatura.

Dê uma olhada sobre o conceito “Web Start”, que é o melhor meio de publicar uma Applet na Web.