The lastest java update form apple, Java 6 update 3, which is version 1.6.0_22 causes major problems when installing the smart client. With previous versions of java, the user would get a pop-up dialog asking them to accept/install the plugins or bean, and they would only get the dialog ONCE per certificate. So for example, only once for Servoy official plugins, only once for IT2BE plugins, etc. Now, since the update, the user gets the dialog asking to accept/install for EACH component (even if it uses the same certificate).
To test this, clear your java cache, and in the Security area, clear out all of the signed extensions you have accepted, (in both areas, for signed content (top) and signed extensions (bottom).
Then do an install of the smart client and you will see the problem. On my install, I received the following dialogs. Note that on the mac, each individual one takes 3 clicks (3 windows prompts for each component)
Servoy Client Beans: 7
Servoy Client Plugins: 17
Cryptor Plugin (IT2BE)- 1
Core Components (IT2BE)- 1
Cryptor Component Extensions (IT2BE)- 1
Tools Plugin (IT2BE)- 1
Log Plugin (Patrick)- 1
Cryptor Plugin (Date Utils)- 1
…etc
In all, there were bout 30 different components to accept, which with 3 clicks for each dialog was 90 clicks to get the smart client installed. Once installed, you don’t received the prompts again. Also noticed that if you had previously installed the Smart Client, under an earlier version, like java 1.6.0_20, and you then upgrade, you also dont receive the extra prompts again. It only happens on a fresh install on the Mac with java 1.6.0_22. I have replicated this problem on several Mac’s.
This was done on Servoy 4.1.7 i1-build 691. Servoy running Windows, with Java 1.6.0_22-b04. Client running Mac with java 1.6.0_22
I seem to remember in previous java versions on the mac that there was like an extra checkbox or option in the dialog that allowed you to accept for all components with same signature or something, but that isn’t an option any more.
I don’t think that would help. For example, I had to accept the default servoy plugins 17 times. Seems like in Mac, its based on per component, but in Windows, based on per certificate. However, I’ll give it a try tomorrow. I’m also wondering if building my own JNLP file instead of using the Servoy generated one will fix the problem. It appears that on the Mac, its showing the install/accept dialog for each <extension name"…" that is listed in the jnlp. Maybe if I instead list them all out in a single jnlp without extension it will work. I’ll give it a try.
On the Mac client.
Go to Java Preferences
and in Advanced
turn off
Verify Mixed security code (sandbox vs. trusted)
No, that doesn’t make a difference. I have done several tests with the JNLP files and can confirm that with Java 6 Update 3 on mac, you get the security dialog for each extension listed in the JNLP file. Which with Servoy, means a dialog for each plugin/bean.
I have successfully been able to create my own JNLP file and instead of listing each plugin as an extension, and each plugin having their own JNLP file, I have grouped the plugins together by signing certificate. So if I put all the servoy plugins in a servoy.jnlp, the it2be plugins in a it2be.jnlp, etc, and then create my own main jnlp launcher file listing each of those as an extensions, then it does work as expected. But that is a real pain to do and manage/maintain.
I have tested this, updated to the latest OSX Java.
cleared my java cache, and removed all the java certificates.
And I get the trust-popup window only once!!
(I use the latest signtester.jar, which I sign everything with my own, locally created certificate)
Well, I have 2 different servers across at least 5 different mac’s all having this problem. Are you running 10.6? Also, My Servoy server is 4.x, not 5.x
We also found as Harjo did - no special problems, running Servoy 5.x on server and client.
goldcougar:
Well, I have 2 different servers across at least 5 different mac’s all having this problem. Are you running 10.6? Also, My Servoy server is 4.x, not 5.x