Continua sessione browser in JNLP

Question

Abbiamo l'autenticazione di base abilitata su Tomcat6. L'utente viene autenticato nel browser e quindi viene avviato JNLP per avviare l'applicazione in Java Web Start. All'avvio, java web start tenta di scaricare i file jar dal server ma non sta utilizzando la stessa sessione che è già autenticata dal browser. Basato sui forum, ho provato a passare l'ID di sessione in JNLP usando la proprietà sid e aggiungendo l'URL. L'ambiente è limitato, quindi ogni richiesta deve essere autenticata, non possiamo dire di escludere richieste di file jar non autenticate. Di seguito è riportato il mio JSP che crea il file JNLP, chiunque può aiutare come possiamo continuare la stessa sessione per scaricare i file jar già autenticati dal browser.

<% response.setContentType("application/x-java-jnlp-file"); %> 
<%= "<?xml version=\"1.0\" encoding=\"utf-8\"?>" %> 
<!-- JNLP File for SimpleTableDemo --> 
<% 
String baseURL = request.getRequestURL().toString().replace(request.getRequestURI(), request.getContextPath()); 
%> 
<jnlp codebase="<%=baseURL%>"> 

    <information> 
     <title>Simple Table Demo Application</title> 
     <vendor>Try</vendor> 
     <description>SimpleTableDemo</description> 
     <description kind="short">An application that demonstrates a simple table.</description> 
    </information> 

    <resources> 
     <j2se version="1.6+" /> 
     <property name="sid" value="<%=request.getSession().getId()%>" /> 
     <property name="serviceHost" value="<%=request.getServerName()%>"/> 
     <property name="servicePort" value="<%=request.getServerPort()%>"/> 
     <jar href="AuthenticateJNLPJars.jar;JSESSIONID=<%=request.getSession().getId()%>" /> 
    </resources> 

    <application-desc main-class="SimpleTableDemo" > 
    </application-desc> 
</jnlp> 

Answer 1

Perché si crea il tuo JNPL con JSP si può passare al vostro applet una discussione con un po 'di token di sicurezza o l'ID di sessione, quindi l'applet deve passare quel valore quando richiesta di informazioni dal server.

Controllare questo: Generate JNLP dynamically

Answer 2

Sei davvero vicino !, ma il vostro livello di sicurezza ha bisogno di più componenti.

La chiave è la variabile baseURL, crea un URL per puntare a un servlet piuttosto che rispondere con i file richiesti dall'applet e aggiungere ad esso il token di sicurezza o il ticket. Come questo:

/codebaseServlet/ABC123123 

Fai il codebaseServlet per estrarre e convalidare il token di sicurezza e risponde con i file richiesti. E ora sii libero di implementare la tua sicurezza come desideri. È possibile effettuare il token di protezione sia valida per un certo tempo, o durante la sessione utente esiste, Convalida modulo IP la richiesta proviene, ecc

Controlla: http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/codebase_determination.html

Answer 3

Io ora ho (alcune) risposte ....

Mi rendo conto che questa domanda ha un anno, ma dal momento che è il primo risultato su google durante la ricerca di questo problema, ho pensato che fosse una buona idea completarlo.

C'è un problema con il codice jnlp che hai fornito, ma prima devi controllare se l'aggiunta del cookie all'URL funzionerebbe davvero ..... e ciò dipende dalla configurazione di distribuzione dell'app.

Non so come sia su Tomcat ... Sto usando weblogic, e in essa si deve il check-in weblogic.xml seguente

<session-descriptor> 
     <url-rewriting-enabled>true</url-rewriting-enabled> 
</session-descriptor> 

Ciò significa che, se disponibile, weblogic otterrà l'id della sessione dall'URL (usando lo stesso formato che hai nel tuo codice)

Se è falso, allora questa soluzione non funzionerà e dovrai inviare un cookie con l'id di sessione in ogni richiesta .... e se hai trovato un modo per farlo rispondere PER FAVORE .... mi sarebbe di grande aiuto.

ora, se l'url-riscrittura-abilitazione è vera, allora questo approccio funzionerà una volta risolto il seguente problema nello script.

Il problema è che, una volta java web start scarica jnlp dal browser, lo scaricherà nuovamente dal server, quindi è necessario assicurarsi di aggiungere anche l'id di sessione a tale richiesta.lo si fa dal modifiing il tag iniziale, in questo modo:

<jnlp spec="1.0+" codebase="<%=baseURL%>" href="<%=NAME_OF_JNLP%>;JSESSIONID=<%=SESSION_ID%>"> 

E questo è tutto, il codice dovrebbe funzionare ...

tra l'altro, le proprietà che sono state aggiunte:

<property name="sid" value="<%=request.getSession().getId()%>" /> 
<property name="serviceHost" value="<%=request.getServerName()%>"/> 
<property name="servicePort" value="<%=request.getServerPort()%>"/> 

non sono rilevanti per questo, è possibile eliminarli e il codice funzionerà ancora.

Answer 4

(non ho privilegi sufficienti per aggiungere un commento, quindi sto mettendo questo come una risposta separata.)

Argod ha scritto:

Il problema è che, una volta Java Web avvia get jnlp dal browser, lo scaricherà nuovamente dal server, quindi devi assicurarti di aggiungere anche l'id di sessione a quella richiesta. lo si fa dal modifiing il tag iniziale, in questo modo:

<jnlp spec="1.0+" codebase="<%=baseURL%>" href="<%=NAME_OF_JNLP%>;JSESSIONID=<%=SESSION_ID%>"> 

Argod, quando si aggiunge un attributo href al jnlp elemento, effettivamente fare JWS per scaricare il file JNLP di nuovo dal server .

Check out Unofficial Java Web Start/JNLP FAQ. Ecco cosa dice:

Un trucco è assicurarsi di non includere l'attributo href nel file JNLP che il servlet restituisce a Web Start. In questo modo Web Start disabiliterà il controllo degli aggiornamenti sui file JNLP e Web Start non tratterà ogni nuovo file JNLP come un aggiornamento dell'applicazione, ma solo i file jar aggiornati.

Ho appena controllato localmente. Con un attributo href, il file jnlp viene effettivamente scaricato tre volte e il file jar viene scaricato una volta. Vedere i miei registri di Tomcat:

127.0.0.1 ... "GET /my-servlet/jws/myjws.jnlp;JSESSIONID=58080491243456B6A653682FA0A3A738 HTTP/1.1" 200 741 
127.0.0.1 ... "GET /my-servlet/jws/myjws.jnlp;JSESSIONID=58080491243456B6A653682FA0A3A738 HTTP/1.1" 200 741 
127.0.0.1 ... "GET /my-servlet/jws/myjws.jnlp;JSESSIONID=342082FEA657D765699EADAF5486E9A7 HTTP/1.1" 200 741 
127.0.0.1 ... "GET /my-servlet/jws/myjws.jar;JSESSIONID=342082FEA657D765699EADAF5486E9A7 HTTP/1.1" 200 7555 

Nota come alla fine viene assegnato un nuovo JSESSIONID, che è negativo. D'altra parte, senza alcun attributo href , file JNLP viene scaricato una volta, e file jar viene scaricato una volta, e JSESSIONID è conservato:

127.0.0.1 ... "GET /my-servlet/jws/myjws.jnlp;JSESSIONID=58080491243456B6A653682FA0A3A738 HTTP/1.1" 200 672 
127.0.0.1 ... "GET /my-servlet/jws/myjws.jar;JSESSIONID=58080491243456B6A653682FA0A3A738 HTTP/1.1" 200 7555 

altro luogo di interesse, è che i nomi prorerty come "sid" "serviceHost", "servicePort" (come OP utilizzato) verranno rifiutati da JWS.

<property name="sid" value="<%=request.getSession().getId()%>" /> 
<property name="serviceHost" value="<%=request.getServerName()%>"/> 
<property name="servicePort" value="<%=request.getServerPort()%>"/> 

nuovo, controllare fuori Unofficial Java Web Start/JNLP FAQ. Ecco cosa dice:

È possibile impostare le proprietà per app non attendibili/non firmate nel file di avvio XML solo se la proprietà è "attendibile". Attualmente le proprietà di fiducia includono:

• javaws *
• jnlp *
• javax.swing...defaultlf
• sun.java2d.noddraw

In altre parole, se si desidera passare la vostra proprietà per la vostra applicazione prefisso con javaws, ad esempio, utilizzare javaws.myproperty invece di MyProperty.

Lo stesso vale per le applicazioni JWS attendibili/firmate.