I have the following line which caused this error message run under JNLP :
java.security.AccessControlException: access denied (javax.sound.sampled.AudioPermission record)
at java.security.AccessControlContext.checkPermission(Unknown Source)
TargetDataLine targetDataLine.open(audioFormat);
How to fix it ? Or does that mean in JNLP, we can't record sound ?
PS : I'm not running it in all-permissions mode, because it requires a 3rd party paid cert. to sign the jar before I can submit my app to Sun's Java Store. I wonder if there's any other way, like using JNLP's FileSaveService / FileOpenService ?
Frank
If you add the following to your JNLP (sibling to </infomration>, does it work?
<security>
<all-permissions/>
</security>
By default, you do not have access outside the applet sandbox, including audio.
Related
Recently we had to upgrade to Java JRE to 1.8.0_201 for an old web application using a single signed Applet. Since then, on starting the applet the "Do you want to run this application?" pop-up window is shown with the detailed information "This application will run with unrestricted access which may put your computer and personal information at risk. Run this application if you trust the location and publisher above."
According to this oracle article this is caused because the manifest does not contain the Permissions attribute. Validation shows that the MANIFEST.MF does contain the attribute.
Manifest-Version: 1.0
Application-Name: MyApplet
Implementation-Title: My Applet
Svn-Url:
Job-Name:
Implementation-Version: 3.12.0-SNAPSHOT
Build-Number:
Archiver-Version: Plexus Archiver
Built-By: username
Implementation-Vendor-Id: nl.myorg.myapplet
Application-Library-Allowable-Codebase: *.myorg.nl
localhost
127.0.0.1
Implementation-Vendor: My Organisation
Build-Tag: 3.12.0-SNAPSHOT
Caller-Allowable-Codebase: *.myorg.nl localhost 127.0.0.1
Permissions: sandbox
Codebase: *.myorg.nl localhost 127.0.0.1
Svn-Revision-LastChange:
Created-By: Apache Maven 3.1.1
Build-Jdk: 1.8.0_171
Svn-Revision:
I think this issue is related to Java Applet & Web Start - Code Signing. So i tried to run the applet in a sandbox to prevent the asking users for full permissions.
I added the <Permissions>sandbox</Permissions> entry to the applets manifest.
Changed the security settings in the applets jnlp from
<security>
<all-permissions/>
</security>
to
<security>
<j2ee-application-client-permissions />
</security>
And added <PARAM name=permissions value=sandbox> to the <applet></applet>.
After making these changes a pop-up is shown with 'ExitException: The Java security settings have prevented this application from running. You may change this behaviour in the Java Control Panel.'.
The Java Console does give some more details;
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
java.lang.SecurityException: JAR manifest requested to run in sandbox only: http://localhost:8080/MyApplet/static/3.12.0-SNAPSHOT/applets/MyApplet.jar
at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at sun.plugin2.applet.JNLP2Manager.prepareLaunchFile(Unknown Source)
at sun.plugin2.applet.JNLP2Manager.loadJarFiles(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
basic: The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.
basic: Dialog type is not candidate for embedding
Since the exception is thrown by DeployManifestChecker.verify could it be that there is an error in the jnlp file ? If so how to determine what is wrong?
Solution is by storing the public key of the applet certificate on a very specific way into the java trusted.certs in the user directory. The trusted.certs is located in \Users{username}\AppData\LocalLow\Sun\Java\Deployment\security.
The certificate has to be loaded similar to the instruction below
"\Program Files\Java\jre1.8.0_201\bin\keytool.exe" -import -alias deploymentusercert$tsflag$loc=http//localhost:8080##jnlp:http//localhost:8080##docbase:http//localhost:8080##from:http//localhost:8080java.util.random#1dc6cb9 -file D:\Desktop\APP-CERT.csr -keystore trusted.certs
The alias seems to be mis-used to store the associated location of the site and jnlp. The alias must have a heading of "deploymentusercert$tsflag$" and a java instance reference to java.util.random as tail text. Inbetween the properties loc, jnlp, docbase and from have to be specified, where the separator between loc and the value is '=' and for the others ':'.
Only issue is that the keystore created through the Java Control Panel has no password. When there is no existing trusted.certs before adding the applets certificate, you will have to write a small Java application or use another tool than keytool to create the keystore. This because keytool does not allow you to create a keystore without a password. Or you could make the world a little bit safer by using a password protected java truststore :-D.
Using Eclipse Kepler (Windows 7) for a project which opens a ServerSocket on localhost, port 80.
I use a security manager with a policy file located at:
C:\Users\John\Developpement\workspace\security\my.policy
In Eclipse, for the project launch configuration properties, for VM arguments:
-Djava.security.manager
-Djava.security.policy=${workspace_loc}/security/my.policy
The bin file executed is (I use separate source and output folders in Eclipse):
C:\Users\John\Developpement\workspace\SocketApps\bin\TinyHttpd.class
In my.policy:
grant codeBase "file:\C:\Users\John\Developpement\workspace\SocketApps\bin\-" {
permission java.net.SocketPermission "localhost:80", "listen,resolve";
};
When running from Eclipse:
Exception in thread "main" java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:80" "listen,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at java.net.ServerSocket.<init>(ServerSocket.java:237)
at java.net.ServerSocket.<init>(ServerSocket.java:128)
at TinyHttpd.main(TinyHttpd.java:35)
when reaching code:
ServerSocket ss = new ServerSocket(80));
If I remove the codeBase filter:
grant {
permission java.net.SocketPermission "localhost:80", "listen,resolve";
};
the problem disappears, so I imagine this is the way the codeBase is expressed that is wrong.
I've tried the solution proposed for this question, but it doesn't work.
Can you help me?
Answering my own question since I found what was the problem.
Not sure if it is better to remove the question, it seems to me that keeping it would help other persons. Moderators to say.
Taken from Oracle documentation:
Note: a codeBase value is a URL and thus should always utilize
slashes (never backslashes) as the directory separator, even when the
code source is actually on a Win32 system. Thus, if the source
location for code on a Win32 system is actually C:\somepath\api\, then
the policy codeBase entry should look like:
grant codeBase "file:/C:/somepath/api/" {
...
}
This is a beginner mistake.
My problem is that program cannot read file (I also don't see pop-up permission window when it's loading!)
It's a JNLP file, in it I got (but still I don't see any pop-ups):
<security>
<all-permissions/>
< /security>
when I execute that file it download some data and run normaly but when I try to load file I get an error:
java.security.AccessControlException: access denied ("java.io.FilePermission" (...) )
I tried to give permision through java system setting and I also tried to change policy files but still it doesnt work.
Inside my Applet, it needs to download the csv file from other site to run.
When i run applet with appletviewer, it gave me this exception :
java.security.AccessControlException: access denied (java.net.SocketPermision www.xxxsitexxx.com:80 connect, resolve
....
My applet's signed :
jarsigner -verify myfile.jar >> the result : jar verified.
I tried to add :
grant {
permission java.security.AllPermission;
};
into Tomcat's folder :
..conf/catalina.policy
But it didn't work.
Google suggests me to add security permisson to :
... jre/lib/security/java.policy
But I couldn't change it :
Access to ... jre/lib/security/java.policy was denied.
My question is :
Does add permission to java.policy solve to problem?
If so, how could I change java.policy's content?
PS : I read many questions here relate to my problem in Stackoverflow, but I couldn't find the right way to solve it.
EDIT : i got the Applet work by signing all jar files that needed to run with the Applet.
I am getting the following exception when trying to run my jar through java web start:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://localhost /ValidatorWEB/validator.jnlp
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
This is the wrapped exception:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
Here is my .jnlp file:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/ValidatorWEB/"
href="validator.jnlp">
<information>
<title>Validator</title>
<vendor>My Company</vendor>
</information>
<resources>
<!-- Application Resources -->
<j2se version="1.6+"
href="http://java.sun.com/products/autodl/j2se"/>
<jar href="WEB-INF/lib/validator.jar" main="true" />
</resources>
<application-desc
name="Validator"
main-class="webstartComponentArch.DynamicTreeApplication"
width="300"
height="300">
</application-desc>
<update check="background"/>
I am deploying the whole thing as a simple WAR to glassfish v2.1 on my local machine. The validator.jar is located in WEB-INF/lib and the jnlp and jsp page I am accessing the jnlp from is at the root of the ValidatorWEB folder.
Googling hasn't helped. I have tried turning my firewall off and it still does the same thing. I have the appropriate Mime-type set in Glassfish. Is there something else I'm forgetting to do?
You do know what http://localhost actually points to? It points to the web server which is running at localhost at port 80. Localhost == 127.0.0.1 == local machine.
As Webstart aka JNLP apps runs at the client machine, it will try to connect the web server at the same (local) machine. You don't want to do that. Change the URL to point to the actual web server at the server machine where your webapp runs and where JNLP is to be downloaded from.
So I figured it out. The problem was where I am specifying the base url:
<jnlp spec="1.0+" codebase="http://localhost/ValidatorWEB/" href="validator.jnlp">
When I deployed to Glassfish, the url that I would access the web application through is actually:
http://localhost:8080/ValidatorWEB/
I had to change my codebase to read:
<jnlp spec="1.0+" codebase="http://localhost:8080/ValidatorWEB/" href="validator.jnlp">
This is something I will definitely have to keep in mind when deploying to a remote server.
Thanks for all of the input!
The spaces after localhost make me suspicious - is there a chance you've defined the hostname with trailing spaces somewhere and web start isn't having any of it?
Also, have you tried simply wgetting (or similar) the listed jnlp URL? The response from the request will let you see what's happening when Java makes the same request.
I dont know if its related but while giving address of resource jar, i would not use "WEB-ıNF/lib", client machine cannot see inside web-inf, you should put that jar inside web application not inside web-inf.
How about the policy file? See here: http://blogs.oracle.com/monzillo/entry/policy_files_the_securitymanager_and