2013-09-08 11 views
5

Sono un programmatore amatoriale. Ho creato un'applicazione che consiste in un singolo file jar autofirmato. L'applicazione verrà utilizzata solo dagli studenti della mia classe di matematica, quindi penso che l'auto-firma sia accettabile.file jar firmato: jnlp non riesce a richiedere all'utente di accettare il certificato

Ho seguito le istruzioni di Oracle per firmare il barattolo e quindi ho utilizzato lo strumento jarsigner per verificare il barattolo. Presumibilmente, andava bene.

Nel file .jnlp, ho inserito il tag di sicurezza con tutti i-permesso:

<security> 
     <all-permissions/> 
    </security> 

Quando il programma lancia, tuttavia, non ho mai visto una finestra di dialogo che chiede all'utente di accettare il certificato o chiedendo per qualche tipo di permesso per l'esecuzione sul computer client. Ho capito che avrei dovuto vedere un simile dialogo, secondo la documentazione di Oracle.

Ho letto questa pagina su StackOverflow:

JNLP get a permission

e ho una situazione simile a quella ottengo un'eccezione di sicurezza. Nel mio caso, l'eccezione viene generata quando l'applicazione tenta di mostrare una finestra FileChooser:

java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read) 

Questo è perché l'utente non è mai stato chiesto di fornire l'autorizzazione. Credo di aver seguito il consiglio su quella pagina StackOverflow, ma non sembra funzionare per me. È come se il barattolo non fosse firmato. Ho anche provato a rimuovere il tag tutti i permessi e ho ottenuto esattamente lo stesso comportamento.

Ho guardato dentro il barattolo e posso vedere che i due file richiesti sono lì: MYKEY.DSA e MYKEY.SF. Ho guardato all'interno del leggibile (.SF) e contiene il testo che dovrebbe essere lì. Credo che sia tutto ciò di cui ha bisogno per essere firmato.

Così qui sono le mie domande:

1) Ha importanza quali i nomi sono di .DSA ei file .SF sono, per quanto riguarda l'applicazione? Al momento hanno solo il nome dell'alias che ho usato con keytool.

2) Ha importanza se la versione java sul mio server è 1.7 mentre la versione java sul mio computer di sviluppo è 1.6? Ho bisogno di compilare la versione 1.6 perché la nostra scuola non ha aggiornato alla versione 1.7, quindi quando viene eseguita sui computer client deve essere 1.6.

3) C'è un modo per determinare quale versione di jarsigner sto usando quando la eseguo dal terminale? Ho provato jarsigner -version, ma questa non è una delle opzioni. Ho notato che la parte superiore del file MYKEY.SF assomiglia a questo:

Signature-Version: 1.0 
    Created-By: 1.4.2-02 (Blackdown Java-Linux Team) 
    SHA1-Digest-Manifest: OHMs6w/CQlG3MVYNxC7l1vTWdZw= 

    Name: org/arps/tranz/TranzActionMap.class 
    SHA1-Digest: dSI3RKfgUrRHbwnZLyXbkiJLWdU= 

Questo significa che non v'è in realtà una versione precedente di jarsigner esecuzione? Non pensavo che Java 1.4 fosse ancora sul mio computer. In ogni caso, la mia versione di jarsigner sembra creare lo stesso tipo di file come si vede qui:

http://docs.oracle.com/javase/tutorial/deployment/jar/intro.html

Non so se i file creati da una jarsigner 1.6 o 1.7 jarsigner un aspetto diverso, o se dovrebbe importare.

4) Se la versione di jarsigner è il colpevole, come posso forzare una versione più recente di jarsigner da eseguire dal terminale (Ubuntu)?

Grazie per il vostro aiuto. Come ho detto all'inizio, sono un programmatore amatoriale. Tutto ciò che voglio veramente fare è essere pronto per le mie lezioni la prossima settimana.

UPDATE:

Dopo aver lottato per un po 'di tempo con uno strumento vaso che non riusciva a trovare libjli.so, ora ho usato con successo lo strumento e jarsigner strumento 1.6 vaso, in modo che la parte superiore del MYKEY. file di SF è simile al seguente:

Signature-Version: 1.0 
    SHA1-Digest-Manifest-Main-Attributes: DGUFMaJYirZi//67NI+M5RVi63k= 
    Created-By: 1.6.0_03 (Sun Microsystems Inc.) 
    SHA1-Digest-Manifest: ZPS3aOyPW/tymxbGdfe4/qBVK/g= 

Ma ho ancora lo stesso comportamento, in cui l'applicazione inizia a lanciare senza chiedere all'utente di accettare il certificato. Quindi ora la mia domanda principale è:

È importante che il jar sia stato creato con 1.6 mentre il mio server esegue 1.7?

Non so quanta attività java avvenga effettivamente sul server. Ad un certo punto, passa al computer client, ma presumo che alcune parti di jnlp si siano verificate sul server per prime.

+1

Assicurarsi di convalidare JNLP utilizzando [JaNeLA] (http://pscode.org/janela/). –

risposta

3

In risposta alle vostre domande specifiche:

  1. E 'gestito automaticamente dallo strumento vaso firmatario, non sudare i nomi.
  2. La versione Java del server non è rilevante, a meno che il server non stia compilando il codice. Ma anche allora, app Java. dovrebbe essere "forward compatibile". OSSIA una app. compilato in 1.5, dovrebbe essere eseguito in 1.5, 1.6 1.7 ..
  3. Non penso che lo strumento firmatario jar faccia qualcosa di diverso nella scrittura del file da quando è stato creato, quindi la versione è irrilevante.
  4. Irrilevante in base al punto (3).
+0

Su Mac OS X, è possibile rimuovere un certificato precedentemente accettato dal portachiavi; non sono sicuro di Windows. – trashgod

+0

@trashgod Anche se questo è probabilmente il caso anche per Windows, si noti che l''eccezione di sicurezza ancora in corso' tende ad indicare che il certificato non è nella cache come 'sempre affidabile'. In effetti, dovrei controllare, ma il controllo AFAIR "Consenti sempre" con un certificato autofirmato è stato silenziosamente ignorato dalla VM Oracle. –

+0

Ah, ho letto male; Grazie. – trashgod

Problemi correlati