I'm new here

SecurityManager in JNLP clients like Java-/AdminClient (e.g. for JFileChooser)

Both FirstSpirit clients:

  • Java-/
  • AdminClient

run both in a sandbox environment, due to their JNLP Java-WebStart implementation nature (and starting mechanism). So, there is a Java SecurityManager available that will check access to the local machine initiated by the remotely loaded application (here: Java-/AdminClient)

When you provide a module that is configurable within the AdminClient using a FileChooser option to store some data locally, there might be some problems:

  1. when voting for the JFileChooser dialog, there are some security limitation that have to be clarified
    1. "all-permissions" have to be granted to the "security" tag within the JNLP configuration
    2. the corresponding JAR has to signed via "jarsigner"
  2. another solution would be using the special JNLP API for the file chooser like mentioned here:


- When voting for solution 1.), is it really necessary to adapt the "JNLP" configuration and sign the JAR?
- What would you vote for?

Thanx for your help,

Holger King

0 Kudos
2 Replies
Crownpeak employee

There is another solution to prevent security exceptions: If you click "Configure" on a module name you can grant "AllPermissions" to the module.

Signing the module jar as mentioned in 1) will not help since the module jars are not loaded by the WebStart class loader but by FirstSpirit.

0 Kudos

When having granted "AllPermissions" would you prefer integrating the JFileChooser-API or using the JNLP-API?

0 Kudos