Wir haben die grundlegende Authentifizierung auf Tomcat6 aktiviert. Der Benutzer wird im Browser authentifiziert und JNLP wird gestartet, um die Anwendung in Java Web Start zu starten. Beim Start versucht Java Web Start, JAR-Dateien vom Server herunterzuladen, verwendet jedoch nicht dieselbe Sitzung, die bereits vom Browser authentifiziert wurde. Basierend auf Foren habe ich versucht, Sitzungs-ID in JNLP zu übergeben, indem ich die sid -Eigenschaft verwende und an URL angehängt werde. Die Umgebung ist eingeschränkt, so dass jede Anforderung authentifiziert werden muss. Wir können nicht sagen, dass Anfragen ausgeschlossen werden sollen, dass die JAR-Datei nicht authentifiziert wird. Unten ist meine JSP erstellen JNLP-Datei, kann jemand bitte helfen, wie können wir die gleiche Sitzung fortsetzen, um Gläser herunterladen, die bereits von Browser authentifiziert ist.
%Vor%Ich habe jetzt (einige) Antworten ....
Ich stelle fest, dass diese Frage ein Jahr alt ist, aber da es das erste Ergebnis bei Google ist, als ich nach diesem Problem suchte, dachte ich, es wäre eine gute Idee, es zu vervollständigen.
Es gibt ein Problem mit dem von Ihnen bereitgestellten jnlp-Code, aber zuerst müssen Sie prüfen, ob das Hinzufügen des Cookies zur URL tatsächlich funktioniert ... und das hängt von Ihrer App-Bereitstellungskonfiguration ab.
Ich weiß nicht, wie es auf Tomcat ist ... Ich benutze Weblogic, und darin musst du weblogic.xml die folgende Eigenschaft einchecken
%Vor%Dies bedeutet, dass weblogic, falls verfügbar, die Sitzungs-ID von der URL erhält (unter Verwendung des gleichen Formats wie in Ihrem Code)
Wenn es falsch ist, dann wird diese Lösung nicht funktionieren und Sie müssen ein Cookie mit der Sitzungs-ID in jeder Anfrage senden .... und wenn Sie einen Weg gefunden haben, um das zu tun, bitte antworten Sie .... es würde mir sehr helfen.
Wenn URL-Rewriting-enable jetzt wahr ist, funktioniert diese Methode, sobald Sie das folgende Problem in Ihrem Skript behoben haben.
Das Problem ist, dass, sobald Java Web Start die jnlp aus dem Browser holt, wird es wieder vom Server herunterladen, so müssen Sie sicherstellen, dass Sie die Session-ID auch diese Anfrage hinzufügen. Sie tun dies, indem Sie das ursprüngliche Tag wie folgt ändern:
%Vor%Und das ist es, der Code sollte funktionieren ...
Übrigens, die Eigenschaften, die Sie hinzugefügt haben:
%Vor%sind dafür nicht relevant, Sie können sie löschen und der Code wird weiterhin funktionieren.
(Ich habe nicht genug Privilegien, um einen Kommentar hinzuzufügen, also stelle ich das als separate Antwort dar.)
Argod schrieb:
Das Problem ist, dass, sobald Java Web Start die jnlp aus dem Browser holt, wird es wieder vom Server herunterladen, so müssen Sie sicherstellen, dass Sie die Session-ID auch diese Anfrage hinzufügen. Sie tun dies, indem Sie das ursprüngliche Tag wie folgt ändern:
%Vor%
Argod: Wenn Sie Ihrem jnlp -Element ein href -Attribut hinzufügen, veranlassen Sie JWS, die jnlp-Datei erneut vom Server herunterzuladen.
Lesen Sie Inoffizielle Java Web Start / JNLP-FAQ . Hier ist was es sagt:
Ein Trick besteht darin, das href-Attribut nicht in die JNLP-Datei aufzunehmen, die Ihr Servlet an Web Start zurücksendet. Dadurch wird Web Start angewiesen, die Update-Prüfung für JNLP-Dateien zu deaktivieren, und Web Start behandelt nicht jede neue JNLP-Datei als Anwendungsupdate - nur aktualisierte jar-Dateien werden dies tun.
Ich habe das gerade vor Ort überprüft. Mit einem href -Attribut wird die jnlp-Datei dreimal heruntergeladen und die jar-Datei wird einmal heruntergeladen. Siehe meine Tomcat Logs:
%Vor%Beachten Sie, dass am Ende eine neue JSESSIONID zugewiesen wird, die schlecht ist. Auf der anderen Seite wird die jnlp-Datei ohne href -Attribut einmal heruntergeladen, und die jar-Datei wird einmal heruntergeladen und JSESSIONID wird beibehalten:
%Vor%Ein weiterer interessanter Punkt ist, dass prorerty Namen wie "sid", "serviceHost", "servicePort" (wie OP verwendet) von JWS abgelehnt werden.
%Vor%Sehen Sie sich auch die nicht offiziellen Java Web Start / JNLP-FAQ an. Hier ist was es sagt:
Sie können Eigenschaften für nicht vertrauenswürdige / unsignierte Apps nur dann in der XML-Startup-Datei festlegen, wenn die Eigenschaft "vertrauenswürdig" ist. Zu den derzeit vertrauenswürdigen Eigenschaften gehören:
- javaws. *
- jnlp. *
- javax.swing.defaultlf
- sun.java2d.noddraw
Mit anderen Worten, wenn Sie Ihre eigene Property an Ihre App übergeben möchten, setzen Sie sie mit javaws, zum Beispiel javaws.myproperty statt myproperty.
Dasselbe gilt auch für vertrauenswürdige / signierte JWS-Anwendungen.
Da Sie Ihren JNPL mit JSP erstellen, können Sie ein Argument mit einem Sicherheitstoken oder der Sitzungs-ID an Ihr Applet übergeben. Ihr Applet muss diesen Wert übergeben, wenn Sie vom Server Informationen anfordern.
Überprüfen Sie dies: JNLP dynamisch generieren
Sie sind wirklich in der Nähe !, aber Ihre Sicherheitsschicht benötigt mehr Komponenten.
Der Schlüssel ist die Variable baseURL. Erstellen Sie eine URL, die auf ein Servlet verweist, anstatt mit den vom Applet benötigten Dateien zu antworten und fügen Sie ihm das Sicherheitstoken oder das Ticket an. So:
%Vor% Machen Sie codebaseServlet , um das Sicherheitstoken zu extrahieren und zu validieren und antwortet mit den angeforderten Dateien.
Und jetzt können Sie Ihre Sicherheit frei implementieren, wie Sie es wünschen. Sie können festlegen, dass das Sicherheitstoken für einige Zeit gültig ist, oder während die Benutzersitzung vorhanden ist, validieren Sie das IP-Formular, an das die Anforderung gesendet wird, usw.
Überprüfen: Ссылка
Tags und Links java session java-web-start jnlp