Further observation. With swingbeans.jar removed from the application server/beans folder, the application behaves as expected when downloaded to my text Mac; and also works when downloaded to the two problematic XP machines once I have removed from the PC Java update 19 using their Add/Remove programs control panel.
Edit: Note: when removing Java update 19, a dialog window reported ‘Java update 10’ being removed. Is this a symptom of poor quality assurance on Sun’s part?
For today our remedial process is to remove Java update 19 from machines affected; and to set Java control panels to ‘never update’. We also clean out Java caches: both Resources and Applications; and start over with a fresh download from the server.
Noted, thanks, Johan’s ‘real clean’ approach to clearing the webstart cache.
At the moment it really seems that all jars from core and all the plugins and beans need to be signed and it could be that the have to have the manifest entry: Trusted-Library: true
Some are signed (when necessary) and some are not.
There are also libraries. Some signed, some not…
We found a solution to avoid users logging in without the components.
-in the onopen method of the solution we use ‘plugins.kioskmode.setStatusBarVisible(false)’, which is not accepted when a user clicks “Yes” in the warning dialog
-as firstform we made a screen like this:
This forces the user to restart and click “no” in the warning dialog…
pbakker:
In addition to what Johan already said in the previous post:
Sun/Oracle has pushed a change into update 19 of Java 6 that, in our opinion should have been reserved for a major update (Java 7).
The change in update 19 doesn’t take into account scenario’s Java WebStart scenario’s like Servoy’s (and many, many other software vendors that use Java WebStart) that use libraries, both signed and unsigned and that can be extended with additional libraries of 3rd parties (beans, plugins etc).
This change has broken many Java WebStart implementations, including ours.
The workarounds for now are:
Removal of the /application_server/beans/swingbeans.jar
Make sure your customers do not upgrade to Java 6 update 19
If your customer(s) have already upgraded to Java 6 update 19, the best option would be to downgrade or activate a previous version on Java on their client machines.
If they have upgraded and cannot downgrade, they can disable “verification” under Advanced tab > security > “mixed mode” in the Java Control Panel on the client machine(s) , see: Mixing Signed and Unsigned Code.
Our effort will continue to provide you with a structural solution asap.
Paul
I’ve tested some other (commercial) Java Webstart applications (with a lot of jars) we work with and they work fine without any security message/warning…
Seems to me a case of a lack of pro active maintenance Servoy side cause the signing issues are not new and security in general is in the spotlights for some time…
My motto is : Fix the problem today if you know the problem will arise the next week/month/year…
This doesnt have anything to do with lack of maintenance or something in that direction.
Sun/Oracle changed in a minor release major things what really affects servoys way of doing stuff.
All the resources from the main jnlp file where all signed and permissions where set.
And then we load in everything else as extensions, what in our eyes just lift with our security settings.
This was working fine for years…
Suddenly they changed it and now that second step, the extensions also need to be signed else you will get that warning.
Problem is for Servoy that many of those extensions are not from Servoy… They are from 3th party even fully open source plugins
or internally developed plugins… All those plugins suddenly must be signed (and all there dependencies)… Or you will get that dialog that you will get every time you start the client.
So it seems that from now on, you have have 3 options:
1> only use fully signed plugins and beans (no dialog will be shown)
2> use signed plugins and beans but some are self signed (a dialog will be shown at startup but this dialog does have a checkbox “always trust”)
3> use unsigned plugins or beans then that dialog which comes up now will always come up at every startup… (no option to say “always trust”)
Currently it is even worse because with 6_u19 there is a bug with <3> so that the dialog they show completely hangs. Because of some threading issues inside Sun code
And <3> is current situation we are dealing with.
I already created many bug reports and feature request the last 2 days in Suns bug database, so hopefully they will improve this.
Is there a way that Servoy Development can have new JAVA updates before they get available to the public?
In that case you could test new versions of JAVA and maybe so we can avoid such a situation like this.
Or is Servoy considered as an end-user just like me and all other Servoy users?
We’re downgrading to 6_18, but after a similar problem with that version for us (now fixed by Servoy unsigning one of the jars), my client’s I.T. department is not thrilled/getting tired of going to every workstation to downgrade Java. Now they’re also turning off auto-update on Java on each workstation (with 250 possible workstations at many sites around the county). Thanks to everyone working on this! Appreciated.
Just checking for an ETA on a fix from Sun or otherwise? Everything above doesn’t really work on my install, because of various IT2BE plugins we rely on. Thanks much!
If they have upgraded and cannot downgrade, they can disable “verification” under Advanced tab > security > “mixed mode” in the Java Control Panel on the client machine(s) , see:Mixing Signed and Unsigned Code.
Just tried the above after installing 1.6.0u19 which didn’t work (got the same error regarding swingbeans.jar)
What I need to do to fix this is change the configuration for the j2se version specified in the JNLP file for the smart clients –
……
to
……
Please let me know how I can configure this in Servoy.
ellenmeserow:
Just checking for an ETA on a fix from Sun or otherwise? Everything above doesn’t really work on my install, because of various IT2BE plugins we rely on. Thanks much!
Hi Ellen, I have done the basic work for Servoy 4/5 last week. That means that all components and libraries are signed and as far as I can see it works. However there are 2 hurdles to take:
I need a build from Servoy to test (Servoy will send me a temp build but I have no ETA for that).
The jars are now self-signed. That is not what I want so I ordered a certificate. However, I was told that the verification process can take a couple of days. I will not release before I received the certificate because otherwise everybody has to update twice.
An explanation for plugin developers to workarround the security level change can be found here, for use with Servoy 5.1.2 or (soon to be released) Servoy 4.1.6
Yes, Servoy 3.5.11 is expected next week … but it is still far better to move on to Servoy 5
As announced over a year ago, the support on Servoy 3.5 will expire soon.
Can anyone tell me – we’ve finally gotten all of our plugins to their signed versions, but we’re being forced to clear the java cache of all servoy smart client machines in order to launch properly – is there any way around this?
Great! I thought of updating their versions in the jnlp from an old piece of advice Marcel gave me, but then didn’t know what to do when I see that Marcel’s plugins now say %%version%%. So I guess it’s not his that I have to worry about. Perhaps its the bean I’m using from ObjectPlanet that doesn’t come with a jnlp file – I just put the jar in the beans folder?