Is it unrealistic to try to control access to JWS files? Is anyone doing this?
It is not unrealistic, and we are doing it. Create a protected web page with a download button or link that makes a servlet call. If the user has already logged in to your website, of course they can go there without further authentication. The servlet reads the cookies sent by the browser when the link is activated. It then generates a dynamic JNLP file adding the authentication cookie and any other required cookies (JSESSIONID, etc.) via <argument> tags. Write the WebStart application so that it picks up any required cookies from the argument list, and adds these cookies to its request headers on subsequent calls to the server. (Note: in the dynamic JNLP file, do NOT put href= in the opening jnlp tag. If you do, JWS will try to reload the JNLP from disk and since it's dynamic, it won't be there. Leave it off and JWS will be happy.)
When returning the dynamic JNLP, the servlet should invoke setHeader( "Expires", 0 ) and addDateHeader() twice on the servlet response to set both "Date" and "Last-Modified" to the current date. This keeps the browser from using a cached copy of a prior dynamic JNLP obtained from the same URL.
Note also that the JAR file(s) for the JWS application should not be on a password-protected path - the launcher won't know about the authentication cookie. But once the application starts, you can run all its requests through a protected path requiring the authentication cookie, because the application gets it from the dynamic JNLP. Just write it so that it can't do anything useful without going through a protected path or doing something to present credentials that could only have come from a valid user. |
java.net RSS Feeds
