I'm trying to run a simple Java Web Start App. I wrote my code in NetBeans and used the jar exported for my .jnlp file. Eventually I plan on having the code read from the windows registry and use that data, but for now all I'm doing is creating a String then calling System.out.println(strName); I am self signing the jar using the strategy outlined here. When I download and run the .jnlp, I get the following exception:
java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jna.debug_load" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at java.lang.Boolean.getBoolean(Unknown Source)
at com.sun.jna.Native.<clinit>(Native.java:95)
at com.sun.jna.Pointer.<clinit>(Pointer.java:41)
at com.sun.jna.platform.win32.WinReg$HKEY.<init>(WinReg.java:32)
at com.sun.jna.platform.win32.WinReg.<clinit>(WinReg.java:61)
at cvbxtractor.CvbXtractor.main(CvbXtractor.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have tried adding permission java.util.PropertyPermission "jna.debug_load", "read"; to my java.policy file, I have tried signing and resigning any jars it might be using, and made sure my .jnlp has the
<security>
<all-permissions/>
</security>
line in it, but none have helped. I'm sure I'm just missing some security toggle somewhere, if this is easy please forgive me, this is my first Java Web Start App.
As of java 7u45, you can't read system properties when running from a jnlp. Oracle basically ruined javaws. If you're writing a new app, I would recommend staying away from java webstart. It's broken and they just keep making it worse by forcing security updates that break your application.
That being said, one partial workaround to this problem is to prefix all of your properties with jnlp.. So, you'd have to rename your property jnlp.jna.debug_load. If it's a property from a third party library/jar you're using, you're out of luck.
Related
I'm working on JavaFx, and we need to run our app on JNLP Web Start, we have faced some problem, and we solved them, now, we have an error in SocketPermission on JNLP runtime.
My problem happens when I call an HTTP request to our server(APIs), the App can't call the request due the permission is denied :
java.security.AccessControlException: access denied ("java.net.SocketPermission" "192.168.1.16:8080" "connect,resolve")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown Source)
at sun.plugin2.applet.FXAppletSecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:74)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
Some Developers said I should have change the java.policy file in my JRE, and said it's wrong way to solve it, but i did this way and nothing happened.
Is there other ways to solve this problem ?!
Add the below section to your JNLP file:
<security>
<all-permissions/>
</security>
I am trying to start the network server from outside netbeans. I did set the DERBY_INSTALL variable to the appropriate directory, then i issue setNetworkServerCP command which also works fine. But when i try to run startNetworkServer i am getting the following error.
C:\Users\tandons>D:
D:>cd D:\netbeans\glassfish-v2.1\javadb\bin
D:\netbeans\glassfish-v2.1\javadb\bin>setNetworkServerCP DERBY_HOME or
DERBY_INSTALL not set. Set one of these variables to the location of
your Derby installation. D:\netbeans\glassfish-v2.1\javadb\bin>set
DERBY_INSTALL=D:\netbeans\glassfish-v2 .1\javadb
D:\netbeans\glassfish-v2.1\javadb\bin>setNetworkServerCP.bat
D:\netbeans\glassfish-v2.1\javadb\bin>SET
DERBY_INSTALL=D:\netbeans\GLASSF~1.1\j avadb
D:\netbeans\glassfish-v2.1\javadb\bin>set
CLASSPATH=D:\netbeans\glassfish-v2.1\j
avadb\lib\derbynet.jar;D:\netbeans\glassfish-v2.1\javadb\lib\derbytools.jar;
D:\netbeans\glassfish-v2.1\javadb\bin>setNetworkServerCP
D:\netbeans\glassfish-v2.1\javadb\bin>SET
DERBY_INSTALL=D:\netbeans\GLASSF~1.1\j avadb
D:\netbeans\glassfish-v2.1\javadb\bin>set
CLASSPATH=D:\netbeans\glassfish-v2.1\j
avadb\lib\derbynet.jar;D:\netbeans\glassfish-v2.1\javadb\lib\derbytools.jar;D:\n
etbeans\glassfish-v2.1\javadb\lib\derbynet.jar;D:\netbeans\glassfish-v2.1\javadb
\lib\derbytools.jar;
D:\netbeans\glassfish-v2.1\javadb\bin>startNetworkServer Security
manager installed using the Basic server security policy. access
denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkListen(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.(Unknown Source)
at javax.net.DefaultServerSocketFactory.createServerSocket(Unknown Sourc
e)
at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocke
t(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknow
n Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Sou
rce)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unk
nown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unkno
wn Source)
at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
D:\netbeans\glassfish-v2.1\javadb\bin>
also is there a better way to do this from within a java program. I read the official doc given on Apache website( using NetworkServerControl api ) but i can make hardly anything out of whats given there..........
This is a known bug. Workarounds are described in the links below. (Google is your friend):
Netbeans bug report
Blog 1
Blog 2
I am using an applet in my web application.
I create self-signed applet jar file and compile classes using Oracle JDK 1.7.45.
In client side, I use JRE 1.7.51 and import the certificate.
The applet works fine in three browsers (IE, Mozilla Firefox, Google Chrome) when I use the application on SSL protocol. The problem is that I got the following NullPointerException when I try to run applet in the chrome and Firefox browser while using the application in http without SSL mode, but it still works in IE.
java.lang.NullPointerException
at sun.plugin2.applet.Plugin2ClassLoader.getTrustedCodeSources(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.strategy(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.openClassPathElement(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
In this link http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html , I see these 2 related 7u45 known issues:
Area: Deployment/Plugin
Synopsis: Applet could fail to load by throwing NPE if pack compression is used with deployment caching disabled.
If a JAR file is using pack compression with manifest entries
Permissions and Caller-Allowable-Codebase while deployment caching is
disabled, then:
• The Permissions manifest entry will be ignored. (This can be seen
from the fact that yellow warning is there on security dialog even
though the Permissions attribute is there.) This only happens if
Caller-Allowable-Codebase attribute is present along with the
Permissions attribute.
• The Caller-Allowable-Codebase attribute will cause the applet to
fail to load by throwing a java.lang.NullPointerException.
If you want to use pack compression with the
Caller-Allowable-Codebase attribute, there are two possible
workarounds:
• Enable caching and all issues listed will disappear.
• Do not use the pack property jnlp.packEnabled=true while deploying
the applets using Caller-Allowable-Codebase andpremissions property.
Instead use the ContentType servlet for serving the pack files.
Area: Deployment/Plugin
Synopsis: Non-JNLP trusted applet fails to load using the file:\ URL. Local trusted applets that do not deploy using a JNLP file will
fail to load by throwing a java.lang.NullPointerException. You can
work around this issue by using one of the following methods:
• Use a JNLP file to launch the applet.
• Try loading the applet over HTTP or HTTPS.
But I don’t use pack compression, also I use a JNLP file to launch the applet and the problem continues to appear.
If your web application is accessed via an authentication step, it is possible that the Java plugins for Chrome and Firefox are unable to download the jar files - when they try to access the URL for the applet, they most probably are greeted by your login page. You could confirm this with Fiddler.
This problem does not appear in IE, because the Java plugin is able to use the session held by the browser itself, so the applet loader is able to immediately download the jar file.
If this is the case for you, the obvious solution is to allow unauthenticated access to the jar file. If you are using IIS, this is done by adding exceptions in web.config.
I've got a Java app that's been in use for awhile and uses embedded Clojure scripts for some of the calculations. Old versions of it still run fine with the current JRE, but if I go to build a new version (only changes to the code are in unrelated Java code) it fails to launch properly. It also runs perfectly fine locally. Only JNLP is affected.
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredConstructors(Unknown Source)
at clojure.core$generate_proxy.invoke(core_proxy.clj:137)
at clojure.core$get_proxy_class.doInvoke(core_proxy.clj:261)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$proxy.doInvoke(core_proxy.clj:335)
at clojure.lang.RestFn.invoke(RestFn.java:1152)
at clojure.lang.Var.invoke(Var.java:465)
at clojure.lang.AFn.applyToHelper(AFn.java:248)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6468)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6546)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6009)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5139)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3751)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:529)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler.eval(Compiler.java:6623)
at clojure.lang.Compiler.load(Compiler.java:7064)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__1451.invoke(core.clj:5530)
at clojure.core$load.doInvoke(core.clj:5529)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$eval1658.invoke(core.clj:6154)
at clojure.lang.Compiler.eval(Compiler.java:6619)
at clojure.lang.Compiler.load(Compiler.java:7064)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.lang.RT.doInit(RT.java:447)
at clojure.lang.RT.<clinit>(RT.java:329)
at myapp(myapp.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The line that it's failing on is this:
RT.loadResourceScript("myapp/clojure_scripts.clj"); // Initialize Clojure script processor with our script
We're currently using a self-signed cert for this app (I've been working with Comodo for the last week trying to get a trusted cert to see if that helps, but I've still not received it and I need this app working ASAP). What's odd to me is that old versions (also self-signed the exact same way) work. I just can't build a new version. I've rolled back my configs so that only actual java code changes should be different, but still no luck. I'm missing something somewhere...
You have to put this into your .jnlp-file:
<security>
<all-permissions/>
</security>
Additionally, depending on your security settings or if using Java 8, add
:manifest {"Permissions" "all-permissions"}
to your project.clj. Clojure requires you to give it the "all-permissions" permission. I'm not entirely sure if it's necessary for all Clojure applications, but I needed to also AOT my project to make it work in a JNLP application. Add this to your ":profiles :uberjar":
:aot :all
:omit-sources true
Trying to run my program through java web start. I get the following exception in the output console. Im new to java web start so do any of you have any ideas?
FYI, here is line 66
ConfigFileReader cfg = new ConfigFileReader(BCApp.getConfigFileLocation());
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
at JCS.Main$setStyle.setStyle(Main.java:66)
at JCS.Main.main(Main.java:57)
... 9 more
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission java.io.tmpdir read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at GUI.BCApp.(BCApp.java:60)
... 11 more
You are going to want to read up on the security manager. Because code launched through Java Web Start could potentially cause grave harm to client computers there are a lot of things it is usually not allowed to do. File system access is one of them. There are several ways to enable your Java Web Start app to access the file system detailed in the documentation.
Your WS application runs from a security sandbox environment, which means it doesn't have an access to the file system, unless a) your app is digitally signed or b) you can modify your security settings (which is not recommended btw).