Webstart Changes Between 6u17 to 6u20: Signed Applications Almost Impossible
Join the DZone community and get the full member experience.Join For Free
Sun/Oracle have done a lot in the latest releases of Webstart, but most of these changes are not very good for us. I am curious to find how others are affected by all these changes.
First we got u17/u18 that broke the desktop shortcuts, because the cached file was already gone, but this is a minor problem. When u19 was released, all our customers deployments of our product (which is a server that serves a Webstart application) didn't work anymore, mainly because of two bugs:
- Certain jar files can't be downloaded: they end up in some kind of exception and "unable to launch application"
- When point <1> was resolved, we got the new mixed code (signing) dialog, but that dialog was triggered from a thread pool thread. And somehow the whole application hangs because the dialog can't be clicked and blocks all input.
I reported both quickly to Sun, I even got on the phone with them, but u20 which was rushed out didn't fix either of those issues. So we now still have to sign everything, all the jars we ship, even if those that are in extensions and don't ask for permissions.
The setup we have is as follows. We have an application server product that serves out a Webstart application, but that webstart application can have plugins and beans from 3rd party vendors or even open source plugins/beans. We did sign the main jars and the rest are loaded in by extensions: until Java 6u19 this was always working pretty fine. Besides that, because everything is dynamic we have to generate the JNLP's at the server side to auto include all the beans and plugins our customers want to use in their application. So then end configuration is not really in our hands..
What we want is what we had before for quite a long time: no warning or security dialogs at all, maybe one information dialog that informs the client (customers of our customer) that they are about to install an application through Webstart that is signed by us.
But there is already something that has changed, I dont know exactly which java update that was, but now it seems that a JNLP file also has to be signed alongside the jar files because if this isn't done, we get a warning dialog that the signature couldn't be verified (which is absolutely not true, our signature/certificate is fine). But it says this because of the unsiged JNLP file. But the JNLP file is generated on the fly and we really can't do anything about that. In our setup that main JNLP file can have infinite number of possible content combinations.
Then I was brainstorming: we have that JNLP file problem, we now have the problem that all plugins and beans including 3th party open source variants need to be signed, or else you get that mixed mode dialog that can't be accepted for every plugin, so clients will get that everytime.
That signing is already a burden on our customers or plugin vendors. We just want to accept everything that comes from the same server.
So I thought about solution like creating a bootstrap application, that is very small and that just creates a ClassLoader itself and we load all the rest ourself. So by passing the Webstart classloader completely we would solve the problem of all the jars needing to be signed. But then the only problem I still have here is that how to pass arguments to that client to also get rid of the first dialog that warns about unsigned JNLP files.
When Java 6u20 came along, which suddenly has an extra requirement that the "codebase" must be in the JNLP. So we have to rewrite the JNLP's anyway! But how can we then sign then the JNLP?
The solution for us would be if javaws would just not try to trust something if it is already trusted. How can we do that? This sounds very easy to me. If javaws sees that the application comes from a https (ssl) site, and that site certificates validates, then everything that comes from that site is trusted automatically.
What do you think?
Opinions expressed by DZone contributors are their own.