2

I've made an applet, which requires access to the user's home catalog. First I signed it with a self signed certificate and everything works if the user accepts the applet security prompt. The problem is that the user's who are going to use the applet from their intranet, have limited permissions on their computers. Therefore, if the user accepts the security prompt and selects "Don't ask again", the modifications (wherever they are stored) are not written to their computers. Rather, the applet will ask for permissions the next time again, and the customer does not want to be prompted every time.

I've tried to overcome this problem by not signing the applet and modifying a policy file instead:

grant codeBase "http://server:port/app/-" {
  permission java.io.FilePermission "${user.home}/-", "read, write, delete";
  permission java.util.PropertyPermission "user.home", "read";
};

but the applet is prompting for permission every time now even if I select "Don't ask again" and I have administrative rights myself on my computer. If I could somehow get it to work using policy files it would be easy to make a script to write the policy files on all the hundreds of computers that will use it.

I guess the question is, can policy files be used in such a way that the users are not prompted at all? The code is trusted by the users anyway so they are fine by having the code run everything that is necessary.

What is the purpose of having policy files if the users are prompted anyway? Then it will be as bad as having the self signed applet asking for permission every time.

Any help or tips are appreciated!

EDIT:

I exported the self signed certificate using the keytool, and imported it on a virtual machine using the keytool into the trusted certs. The applet still asks for permission to run. I also tried the following:

  1. Select "Always allow", now the certificate is saved in "...Application Data\Sun\Java\Deployment\security\trusted.certs"
  2. Export certificate using Control Panel->Java->Security->Manage Certificates->Export
  3. Delete the certificate Control Panel->Java->Security->Manage Certificates->Remove
  4. Import the previously exported certificate using the keytool

The applet still asks for permission, even if the certificate should be the same. However, if I open the trusted.cert in notepad++ I can see that some binary characters differs if the certificate was automatically installed by selecting "Always Allow" compared to importing the certificate using the keytool.

The only option I found to work is to select "Always Allow" on one machine and copy the whole trusted.cert file and replace the trusted.cert file on the target machine. That way it believes the user has already chosen "Always Allow". This does not seem like a good solution.

Edit2: Copying the whole trusted.cert file only worked in my virtual machine. Others who used my trusted.cert could not run the applet without giving it permission first. Perhaps Java is not up for the task, maybe flash is not that restricted.

user979899
  • 141
  • 1
  • 2
  • 14
  • *"I signed it with a self signed certificate"* Sign it with a real certificate and the user can check the box for 'Always Allow'. – Andrew Thompson Jun 11 '13 at 02:00
  • I doubt it will work, because I can select "Always Allow" because I have sufficient permissions on my computer, but if the users select "Always Allow" then Java will forget this choice until next time. I don't think it depends on the certificate, because "Always Allow" works for others who have administrative rights on their computers too, when the applet uses a self signed certificate. – user979899 Jun 11 '13 at 07:00
  • *"Always Allow" works for others who have administrative rights on their computers too, when the applet uses a self signed certificate.* Really? It has ***never*** worked for me since 1.4 (as far back as I recall testing it), and I write code on a PC I control. *"I doubt it will work.."* It sure won't if you don't try it. In any case, why is this an applet? Wrap the applet in a frame and supply that direct to the end user as a runnable Jar and the applet will have *no* security manager. – Andrew Thompson Jun 11 '13 at 07:08
  • Well, at least "Always Allow" works for the other developers who tested it. The certificate gets installed somewhere on their computer and the applet won't prompt them next time. This is confirmed. We have not tested if a paid certificate works differently, we'd hope to avoid paying for it since the users will happily run the code anyway. It is an applet because it needs access to the session on the intranet in order to get data from the database. The users do not have direct access to the database, it is handled in the web application. – user979899 Jun 11 '13 at 07:32

0 Answers0