This content has been marked as final. Show 3 replies
user7539056 wrote:That sounds like a strange way to implement security to me. As a user of a Web Start application I wouldn't really expect that I would have to go to the web site and log in every time I wanted to use the application. I would expect to download it and then be able to use it without the browser from then on.
when I got to the point of adding security (logging in on the server then using a .jsp to generate a .jnlp with the jsessionid for the client load)
And as a producer of Web Start applications it seems to me that your idea is very likely to run afoul of processes which like to cache things. I know that was one of the issues that confounded me the most.
The point of the JWS is to introduce them to the product and to try and induce them to license the full installable version, so I think the design is the right one. If your use case became the more common (or I fot more energy) I could toss in code to handle the web login for the cases when I start without a jsessionid.
Perhaps an applet would be a better approach for the introductory version, then? You could pass the jsessionid as an applet parameter in the HTML page containing the applet... although in this case the applet shares the session with the browser so you don't really need that. And you can use JNLP features in applets. (Or so I hear... haven't really looked into that.)