This will be really tricky because we need to generate a jnlp file as a file
Include that in the j2db.jar (the main jar) and then sign that one again.
I guess you could do that your self now if you resign everything..
here is a snippet of the jnlp spec how to do that:
5.4.1 SIGNING OF JNLP FILES
A JNLP file can optionally be signed. A JNLP Client must check if a signed version of the JNLP file
exists, and if so, verify that it matches the JNLP file that is used to launch the application. If it does not
match, then the launch must be aborted. If no signed JNLP file exists, then the JNLP file is not signed,
and no check needs to be performed.
A JNLP file is signed by including a copy of it in the signed main JAR file. The copy must match the
JNLP file used to launch the application. The signed copy must be named: JNLPINF/
APPLICATION.JNLP. The APPLICATION.JNLP filename should be generated in upper case,
but should be recognized in any case.
The signed JNLP file must be compared byte-wise against the JNLP file used to launch the application. If
the two byte streams are identical, then the verification succeeds, otherwise it fails.
As described above, a JNLP file is not required to be signed in order for an application to be signed. This
is similar to the behavior of Applets, where the Applet tags in the HTML pages are not signed, even when
granting unrestricted access to the Applet.
Big problem here is that if you would get the standard jnlp file:
http://yourserver/servoy-client/servoy_client.jnlpand save that file to disk. and include that as the APPLICATION.JNLP file in the JNLPINF/ dir in the j2db.jar (besides the meta-inf i guess)
then you don't (or shouldnt) get the warning if you really start it by that url
But if you are using other entry points like profiles or a deeplink directly to a solution, or change anything on the admin pages (like system properties or vm properties)
that affect the jnlp file then it doesn't work anymore..
So for us to make this work we have to somehow generate the j2db.jar for every request and then somehow know what jnlp is used to get that jar file (so if possible we should have some kind of session at the server)
then include that jnlp file quickly in the jar for that specific client, sign the jar and serve the jar
as you can see thats quite a bit of work.. and maybe it is not even possible to do.. (we really have to link the right jnlp file the client uses to the j2db.jar that it downloads which are 2 totally separated request to the server)
I do have some other idea that i have to work out to by pass all of this. I only don't know if this will really work need to work on a prototype first.