Signed JNLP restrictions

Hi all,
I have a java application distributed as a signed JNLP.
Inside this application I can read/write stuff to the filesystem, read system properties, etc... but I'm getting one issue that I believe it wasn't happening with jdk 1.5.
I'm trying to enable the ARD from the JNLP, so I invoke osacript with administrator privileges to run kickstart.
This is what I'm getting:
stdErr [0:175: execution error: Security API failed with error -2129264641. (1)]
I have also tried using 'sudo' and the result is:
stdErr [/bin/sh: /usr/bin/sudo: Operation not permitted]
Is there any restriction somewhere for signed JNLP apps?
Many thanks for your inputs!
Luis

>
I have an application that has been distributed via WebStart without problem for a while. Recently (since 1.6.0_11) we started getting warnings because our JNLP file sets restricted properties, so we had to sign the JNLP.>'Sign the JNLP'? Do you mean 'requested extra permissions in the JNLP, and signed the Jar files'? The second I am quite familiar with, the first I have never heard of. The rest of your post sounds similarly bass-ackwards.

Similar Messages

Issue With Signed JNLP file

Hello,
There seems to be a restriction in signed JNLP files with regards to relative path set in codebase ?
(when we set the codebase to be a full url of the download site it works.).
The problem for us is we want JNLP file for dev and Prod to be identical and not having to hardcode
download URL.
We have a start.jnlp which start our app. All our jars are signed. To avoid the usual warning message
we decided to sign the JNLP file and include JNLP-INF/APPLICATION.JNLP in our jar that contain the main file.
//start.jnlpl and APPLICATION.JNLP have the following
<?xml version="1.0" encoding="utf-8"?>
<jnlp codebase="webstart" href="start.jnlp">
</jnlp>
Error/Exception
BadFieldException[ The field <jnlp>codebase has an invalid value in the signed launch file: webstart,webstart]
     at com.sun.javaws.jnl.XMLUtils.getAttributeURL(Unknown Source)
     at com.sun.javaws.jnl.XMLFormat.parse(Unknown Source)
     at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
     at com.sun.javaws.LaunchDownload.checkSignedLaunchDescHelper(Unknown Source)
     at com.sun.javaws.LaunchDownload.checkSignedLaunchDesc(Unknown Source)
     at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
     at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
     at com.sun.javaws.Launcher.launch(Unknown Source)
     at com.sun.javaws.Main.launchApp(Unknown Source)
     at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
     at com.sun.javaws.Main$1.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Any input will be greatly appreciated.
Thanks
Jc

>
There seems to be a restriction in signed JNLP files with regards to relative path set in codebase ?
(when we set the codebase to be a full url of the download site it works.).>That is a problem. Sun seems to think there are many forms of launching where the codebase must be explicitly set for the JNLP to work correctly, and this is one of them. In fact, the only time I know it will work with a relative codebase is when embedding an applet using JNLP - and then it has to have no codebase to work!
>
The problem for us is we want JNLP file for dev and Prod to be identical and not having to hardcode
download URL.>But this is really a matter of approaching the problem the most efficient way, and I would argue that way is to write a build file which will make both versions of the application. It might require a more complicated build file (OK - it will require a more complicated build file), but once it is done you will barely notice any difference in build time, and you can get on with development.

Signed JNLP file doesn't match JNLP file on webserver?

Hi,
using Java 1.6.0(_13) Webstart says, that the JNLP file is not signed.
So I added my JNLP file as JNLP-INF/APPLICATION.JNLP into the client jar.
I signed my jar with my cert from thawte and copied the JNLP file to the unix webserver.
Now Webstart says that the JNLP file from the webserver doesn't match with the signed one.
Does anyone have some practical experience with signing JNLP files and knows the common pitfalls.
What are the issues that could let this fail, CR/LF or a bug ?
Best regards

Its from an Android device? Maybe incompatible Java versions. In Utilities launch the Java Preferences app and look at the enabled version information (General tab). Perhaps click the Restore Defaults button.

Insecure JNLP java_vm_args cannot avoid security alerts even with a signed JNLP

I am using a signed JNLP launch file that is validated against JNLP-INF/APPLICATION_TEMPLATE.JNLP in my main resource JAR (which I know works because if I change the JNLP in an invalid way the Java Plugin JNLP Client complains as expected). The main resource JAR is also properly signed with a real code signing certificate, marked as a Trusted-Library in the Manifest, and has "all-permissions" in the JNLP.
In my JNLP launch file, I have some java_vm_args that are considered insecure. For example, --XX:+PrintGC. Despite the fact that the JNLP is signed, I get two security alerts:
1) A yellow exclamation mark alert which when More Information are examined asserts that the JNLP file is NOT signed.
2) If I accept and run anyway, then I get another alert saying:
"This application is going to perform an insecure operation. Do you want to continue?"
Is there any way to avoid these issues while still being able to specify arbitrary VM arguments for the applet?

Found the answer in your link. :-)
If the Application-Library-Allowable-Codebase attribute is present and matches the location from which the RIA is started, then a single host is listed in the Location field for the prompt and the option to hide future prompts is provided. If this attribute is present and the files are accessed from a location not included for the attribute, then the RIA is blocked. If this attribute is not present, then multiple hosts that correspond to the locations of the JAR file and the JNLP file or HTML page are listed in the Location field for the prompt. When multiple hosts are shown, the user is not given the option to hide future prompts. Use of this attribute is recommended so the files for the RIA are accessed only from known locations.

Signed jnlp and JnlpDownloadServlet

Hi all,
my applet is ran via jnlp. The jnlp file is used inside a web application that deploy many jnlp files using JnlpDownloadServlet from jdk 1.5. I don't know if there is any other preferred method for serving jnlp files (that require a lot of libraries and extensions.)
I changed my applet since I need to create a temporary file on the client machine, so I added all-permission tag (even if jnlp documentation states that this is for java application and doesn't mention applet at all).
Now my applet gets an exception from SecurityManager when opening the file for writing.
So I studied again, and found that JNLP can be signed and (probably) must be signed in order to give all permissions to my applet.
I then added my jnlp file to the main applet jar, naming it as requested. Then I signed the jar again.
Now, the jnlp is correctly downloaded by browser, the signed version is extracted and verified.
Then I get a new error: the jnlp files (the not signed and the signed one) are different.
And indeed they are since JnlpDownloadServlet is changing my jnlp file: codebase is inserted correctly, URL become absolute, comments are stripped out.
Of course I could create a jnlp file (not signed) exactly the same of the signed one, but since my applet is going to be deployed on many servers, I cannot used a fixed codebase inside the jnlp.
So, my question: what should I do?
Thank you very very much,
Giuseppe

I made some further tests and it seems that even having a correctly signed jnlp file, my applet does not get all-permissions.
I tried creating a correct $HOME/.java.policy and of course it works, but I really cannot ask every user to create that file.
Is there any other solution?
Thanks,
Giuseppe

Java 6u24 won't launch signed JNLP app with classes compiled with JDK 1.4.2

Anyone else having a problem launching a JNLP app compiled with Java 1.4 using Java 6u24 on the client? Anyone have a Java 1.4-compiled app that does launch with Java 6u24?
I am, and I have isolated the problem to some change in 6u24's java web start launching logic. The splash screen appears and then javaws just quits with no error. Trace shows it is not getting past checking of the first .jar. My JNLP app, fully signed with CA-issued certificate, when compiled with Java 1.4.2 will not launch on JRE 6u24 (or 6u25-b03). The same exact app launches perfectly fine when it is compiled with JDK 1.5 or 1.6. It is not a signing problem, though it is related to certificate checking logic or a concurrency flaw in javaws' AppPolicy and TrustDecider classes. It is not a host server or network problem as those have been varied with same results. It is not a specific .jar problem as I have varied what is the first .jar with same results. I have eliminated all other variables to find the only difference is what Java version the app is compiled with. Well, all but one other variable - I have not tried with apps other than mine.
My app is compiled with JDK 1.4.2 so I can still support older platforms. That requirement is going away soon but this is still a regression from 6u23 that is causing a big problem for at least this developer.

You can try to use the version of the jarsigner JDK 1.5 or later.
Has changed the management of files in META-INF.
So compile with 1.4 but sign with 1.5 or later

Signing JNLP files?

I just found out that JNLP files can be signed (see JNLP specification section: "5.4.1 Signing of JNLP Files"). What advantage is there to signing the JNLP since the application will run unrestricted even if the JNLP is not signed (but the JAR files are)?

I just found out that JNLP files can be signed (see JNLP specification section: "5.4.1 Signing of JNLP Files"). What advantage is there to signing the JNLP since the application will run unrestricted even if the JNLP is not signed (but the JAR files are)?

Signed JNLP doubles the number of Security Dialogs

I have an Eclipse RCP application that is deployed via WebStart. We have not been signing our top level JNLP and as a result launching the client results in the following dialog with the yellow warning icons. I found a posting about adding the JNLP to the main jar as JNLP-INF/APPLICATION.JNLP (http://jcp.org/aboutJava/communityprocess/maintenance/jsr056/jnlp-7_0-changes.html) . Then when the main jar is signed, the JNLP will be "signed" and the warnings on the launch dialog will be changed to informational.
When I make this change to my main jar and launch the application, I do indeed get the java icon and the blue information shield but my users are prompted with the "Do you want to run this application" twice. JNLP file that is in the top level application directory with an exact copy in the main jar JNLP-INF/APPLICATION.JNLP file. JNLP file provided below:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://local.mycompany.COM/Client" href="client.jnlp">
<information>
<title>Client</title>
<vendor>mycompany</vendor>
<description>Client Application</description>
<shortcut>
<desktop/>
</shortcut>
</information>
<security>
<all-permissions/>
</security>
<update check="always" policy="always"/>
<resources>
<jar href="plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar"/>
<extension name="Wrapper feature" href="features/com.mycompany.client.feature_0.7.0.jnlp" />
<property name="osgi.instance.area" value="@user.home"/>
<property name="osgi.configuration.area" value="@none"/>
<property name="osgi.configuration.cascaded" value="false"/>
<property name="osgi.bundles" value="org.eclipse.equinox.event@2:start,org.eclipse.equinox.ds@2:start,org.eclipse.core.runtime@4:start,org.eclipse.equinox.common@2:start"/>
<property name="eclipse.application" value="com.mycompany.client.application"/>

<property name="logLevel" value="ERROR"/>
<property name="logFile" value="client.log"/>
</resources>
<resources os="Windows" arch="x86">
<j2se version="1.6+" />
</resources>
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
<argument>-nosplash</argument>
</application-desc>
</jnlp>
Side note, with the upgrade to Java 7 Update 21 and an unsigned JNLP our users get the Run prompt plus 14 do you want to install... prompts. When the JNLP is signed this doubles and then now have 2 run prompts and 28 install prompts. Totally unacceptable

Found the answer in your link. :-)
If the Application-Library-Allowable-Codebase attribute is present and matches the location from which the RIA is started, then a single host is listed in the Location field for the prompt and the option to hide future prompts is provided. If this attribute is present and the files are accessed from a location not included for the attribute, then the RIA is blocked. If this attribute is not present, then multiple hosts that correspond to the locations of the JAR file and the JNLP file or HTML page are listed in the Location field for the prompt. When multiple hosts are shown, the user is not given the option to hide future prompts. Use of this attribute is recommended so the files for the RIA are accessed only from known locations.

Problem Packing Signed JARs of more than 10 MB

Hi friends of Java,
there seems to be a size issue when packing signed JARs.
When I try to pack a signed JAR of about 5 MEGs (such as the jbossall_client.jar file) it works (i.e. jarsigner can verify the result),
but if i try doing it with a JAR of about 11 MEGs the jarsigner can't verify the packed (and unpacked again) file.
Example:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\BasisWebClient.jar
06.03.2009 17:32 10.943.963 BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\BasisWebClient.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\BasisWebClient.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\BasisWebClient.jar.pack.gz temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\BasisWebClient.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jarsigner: java.lang.SecurityException: SHA1 digest error for basisweb/vg/presenter/SchluesselBezeichnungDialogPresenter.class
The same with a smaller file:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\jbossall-client.jar
31.08.2007 07:31 4.895.807 jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\jbossall-client.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\jbossall-client.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\jbossall-client.jar.pack.gz temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\jbossall-client.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jar verified.
It also works when I split the original JAR in multiple parts. Any ideas?
Used Java Version:
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
OS: Windows XP Pro Version 2002 SP2
PC: Intel Pentium 4 3.2GHz, 2GB RAM, 160 GB HD
Regards from Germany,
Thomas Nagel

Hello Bryan,
I dont have a solution yet. Currently we use the jars uncompressed. Sad, but that works.
For the future, we are not really sure wether we can stick with JWS, as the signed JNLP-file-issue might make us even more trouble.
I've done some error search. Look at the following.
Try for your own with some different sized jar's, and maybe post the results (definitely if they all pass):
--- snip ----
package ctest;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Map;
import java.util.jar.*;
import java.util.jar.Pack200.*;
* @author tnagel
public class PackTest implements Runnable {
     String test1 = "junit";
     String test2a = "xalan";
     String test2 = "jbossall-client";
String test3 = "BasisWebClient2";
String dir = "/tmp/";
String ext1 = ".jar";
String ext2 = ".jar.pack.gz";
//String infile = "/tmp/BasisWebClient.jar";
//String outfile = "/tmp/BasisWebClient.jar.pack.gz";
//String testfile = "/tmp/testaus.jar";
* @param args the command line arguments
public static void main(String[] args) {
     PackTest me = new PackTest(args);
public PackTest(String[] args) {
this.run();
public void setProperties(Packer packer) {
// Initialize the state by setting the desired properties
Map p = packer.properties();
// take more time choosing codings for better compression
p.put(Packer.EFFORT, "9"); // default is "5"
//// use largest-possible archive segments (>10% better compression).
// p.put(Packer.SEGMENT_LIMIT, "-1");
//// reorder files for better compression.
//p.put(Packer.KEEP_FILE_ORDER, Packer.FALSE);
//// smear modification times to a single value.
//p.put(Packer.MODIFICATION_TIME, Packer.LATEST);
//// ignore all JAR deflation requests,
//// transmitting a single request to use "store" mode.
//p.put(Packer.DEFLATE_HINT, Packer.FALSE);
//// discard debug attributes
//p.put(Packer.CODE_ATTRIBUTE_PFX+"LineNumberTable", Packer.STRIP);
// throw an error if an attribute is unrecognized
p.put(Packer.UNKNOWN_ATTRIBUTE, Packer.ERROR);
//// pass one class file uncompressed:
//p.put(Packer.PASS_FILE_PFX+0, "mutants/Rogue.class");
@Override
public void run() {
     doTest(test1, true);
     doTest(test2, true);
     doTest(test3, true);
     doTest(test3, true);
     doTest(test3, true);
private void doTest(String test, boolean compare) {
String infile = dir + test + ext1;      // "/tmp/BasisWebClient.jar";
String outfile = dir + test + ext2; // "/tmp/BasisWebClient.jar.pack.gz";
String testfile = dir + test+ "-aus" + ext1;
try {
     countJar(infile, false);
     JarFile jarFile = new JarFile(infile);
FileOutputStream fos = new FileOutputStream(outfile);
// Create the Packer object
Packer packer = Pack200.newPacker();
setProperties(packer);
// call the packer
long startTimeMethode =System.currentTimeMillis();
packer.pack(jarFile, fos);
System.out.println("Time for Pack: " + (System.currentTimeMillis() - startTimeMethode));
jarFile.close();
fos.close();
File f = new File(outfile);
FileOutputStream fostream = new FileOutputStream(testfile);
JarOutputStream jostream = new JarOutputStream(fostream);
Unpacker unpacker = Pack200.newUnpacker();
// Call the unpacker
startTimeMethode =System.currentTimeMillis();
unpacker.unpack(f, jostream);
System.out.println("Time for Unpack: " + (System.currentTimeMillis() - startTimeMethode));
// Must explicitly close the output.
jostream.close();
     countJar(testfile, false);
     if(compare) compareJars(infile,testfile);
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
private void countJar(String filename, boolean showDetails) {
     JarFile jarFile1 = null;
     try {
          int entries = 0;
          long sizeTotal = 0L;
          long compressedSum = 0L;
          jarFile1 = new JarFile(filename);
          Enumeration e = jarFile1.entries();
          while(e.hasMoreElements()) {
               JarEntry jarE = (JarEntry) e.nextElement();
               entries ++;
               sizeTotal += jarE.getSize();
               compressedSum += jarE.getCompressedSize();
               if(showDetails) {
                    System.out.println( jarE.getName() + " s= " + jarE.getSize() + " c= " + jarE.getCompressedSize() );
          System.out.println( filename + ": " + entries + " entries, " + sizeTotal + " Byte, compressed " + compressedSum + " Byte" );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
private void compareJars(String erstes, String zweites) {
     JarFile jarFile1 = null;
     JarFile jarFile2 = null;
     try {
          int fehler = 0;
          int entries = 0;
          jarFile1 = new JarFile(erstes);
          jarFile2 = new JarFile(zweites);
          Enumeration e1 = jarFile1.entries();
          Enumeration e2 = jarFile2.entries();
          while(e1.hasMoreElements()) {
               JarEntry jarE1 = (JarEntry) e1.nextElement();
               if(e2.hasMoreElements()) {
                    JarEntry jarE2 = (JarEntry) e2.nextElement();
                    entries++;
                    if(!jarE1.getName().equals(jarE2.getName())) {
                         System.out.println( "Name different at Index= " + entries+ " n1=" + jarE1.getName() + " n2=" + jarE2.getName() );
                         fehler ++;
                         break;
                    if(jarE1.getSize() != jarE2.getSize()) {
                         System.out.println( "Size different at bei " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getSize() + " s2=" + jarE2.getSize());
                         fehler ++;
                    if(jarE1.getCrc() != jarE2.getCrc()) {
                         System.out.println( "CRC different at " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getCrc() + " s2=" + jarE2.getCrc());
                         fehler ++;
                    if(jarE1.getMethod() != jarE2.getMethod()) {
                         System.out.println( "Method different at " + jarE1.getName() + " Index= " + entries + " m1=" + jarE1.getMethod() + " m2=" + jarE2.getMethod());
                         fehler ++;
          System.out.println( "Errors= " + fehler + " entries=" + entries );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
     try { if(jarFile2 != null) jarFile2.close(); } catch (Exception e) { }
--- snip ----
Cheers,
Thomas

The JNLP nightmare - a summary

our application has the following preconditions:
* one EAR should work on the lab, the validation and the production environment with no security warnings
* we have to use 2 jnlp files
* we use native libraries
the conclusion we've drawn: this isn't possible with java webstart
reason:
1. the application has to be signed. hence the JNLP has to be signed. the current and only way to do this is to create a file JNLP-INF/APPLICATION.JNLP. and this is not a pattern, it's the actual filename. so if you have a start.jnlp, you still need to call the signed one APPLICATION.JNLP. this eliminates the possibility to have 2 jnlp files, since calling the not-signed-one doesn't even create a warning, but it creates an error message
2. the usage of placeholders like "$$codebase" is impossible since the signed jnlp file and the one from the webserver can never be identical. the binary comparison fails because the one from the webserver has eg the resolved hostname while the signed one of course has the placeholders. you could remove the placeholders by hardcoding the urls, but this eliminates the possibility of using the same ear in lab, val and prod environment.
3. since we have to use native libraries, we need to use the <security><all-permissions/></security> tags. this of course forces a certificate validation and because of the above we run into warnings
question: does anyone know a way to create a securitymanager/policy file which allows access to everything without getting a warning when you download a jnlp file? leave the security concerns aside, the question is if it is possible at all.
hope this might help others to not waste hours and hours of research only to find out that webstart is very limited
Edited by: user8995776 on Oct 1, 2010 4:55 AM

thank you, i know that link, been through it already during research.
and thank you for your consideration. i'd be glad if you find something that we missed. here's the jnlp code:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="$$codebase" href="$$name">
<information>
    <title>Title</title>
    <vendor>Vendor</vendor>
    <homepage href="http://www.homepage.com"/>
    <description>Description</description>
    <description kind="short">[PENDING]</description>
    <icon href="$$codebase/../icons/icon.gif"/>
    <icon kind="splash" href="$$codebase/../icons/welcome.png"/>
    <offline-allowed/>
</information>
<security>
    <all-permissions/>
</security>
<resources>
    <j2se version="1.5+" java-vm-args="-Xmx300m"/>
    <jar href="myapp.jar"/>
    <jar href="log4j-1.2.15.jar"/>
    <jar href="commons-lang-2.4.jar"/>
    <jar href="commons-cli-1.2.jar"/>
    <jar href="jawin-stubs.jar"/>
    <jar href="jawin.jar"/>
    <jar href="jacob.jar"/>
    <nativelib href="jacob.dll.jar"/>
    <jar href="jbossall-client.jar"/>
    <jar href="swing-layout-1.0.jar"/>
    <jar href="ognl-2.6.7.jar"/>
    <nativelib href="jawin.dll.jar"/>
   </resources>
   <application-desc main-class="com.vendor.MainApp">
    <argument>-param</argument>
    <argument>arg</argument>
</application-desc>
</jnlp> in addition, here's a related bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6653241
and the relevant source code part from java itself:
   private static final String SIGNED_JNLP_ENTRY = "JNLP-INF/APPLICATION.JNLP";
    /** Returns true if the JNLP file is propererly signed - otherwise false
     * Only applications that request unrestricted access needs to be signed
    static private byte[] getSignedJNLPFile(LaunchDesc ld, boolean forceMain)
    throws IOException, JNLPException {
        if (ld.getResources() == null) return null;
        JARDesc mainJar = ld.getResources().getMainJar(forceMain);
        if (mainJar == null) return null;
        // Lookup main JAR file in cache - should already have been downloaded
        // at this point
        JarFile jarf = null;
        try {
            // pass in false to JarFile ctor so no verification will be done to
            // minimize performance impact
            jarf = new JarFile(DownloadEngine.getCachedResourceFilePath(
                mainJar.getLocation(), mainJar.getVersion()), false);
            JarEntry sjfe = jarf.getJarEntry(SIGNED_JNLP_ENTRY);
            if (sjfe == null) {
                // Search no case sensitive
                Enumeration allnames = jarf.entries();
                while(allnames.hasMoreElements() && sjfe == null) {
                    JarEntry jfe = (JarEntry)allnames.nextElement();
                    if (jfe.getName().equalsIgnoreCase(SIGNED_JNLP_ENTRY)) {
                        sjfe = jfe;
            // No entry found
            if (sjfe == null) {
                return null;
            // Read contents of signed JNLP file into bytearray
            byte[] signedJnlp = new byte[(int)sjfe.getSize()];
            DataInputStream is = new DataInputStream(jarf.getInputStream(sjfe));
            is.readFully(signedJnlp, 0, (int)sjfe.getSize());
            is.close();
            return signedJnlp;
        } finally {
            if (jarf != null) {
                jarf.close();
    }

Flash restricted running scripts or activeX controls

Hey, can someone give me a hand?
I read in a different, older forum, that said to use "" but how do i put it
into my flash projects?
If this is not what i should use then what should i use to
remove the sign "flash restricted running scripts or activeX
controls" that pops up when i run the flash on my website.

I thought that only happened when running flash
locally.

Signing and whats next

I've read plenty of pages about signing, jnlp and so on. However I can't figure out how I have to handle the signed jar's.
1. I'v created the jar file from my project.
2. I'v signed the jar file.
3. I'v changed the JNLP Doc to "all permissions".
But it still doesn't work. I'v got still the same error. So, do I'v to include a certificate file in the JNLP File or what else ?
I would expect, that I have to distribute the xxx.cer file and to import in the JAVA Web Start settings am I wrong ?
Thanks for Help

thats all you need to do - theres probably some error in the jnlp file thats causing it to not be parsed correctly. Can you post your jnlp file ?
/Dietz

Invalid number while loading a number with a coma as a group separator

Hi,
I'm loading a file in which I have numbers such as -9,999.99. The point is for decimal and the coma for the group separator (thousands).
I did an alter session with a set to NLS_NUMERIC_CHARACTERS=".,"
I have no errors with numbers such as -999.99 but as soon as I have a number with a thousand such 1,789.44 I got an invalid number error ??
By the way when I tried to do the SQL statement directly, I also got the error
SQL> select to_number('1,789.55','S999G999D99','NLS_NUMERIC_CHARACTERS=".,"') from dual;
select to_number('1,789.55','S999G999D99','NLS_NUMERIC_CHARACTERS=".,"') from dual
ERREUR à la ligne 1 :
ORA-01722: Nombre non valide
What am I missing ? What should I do to avoid the error ?
Thxs in advance for your help.
Rgds
Yves

Look carefully onto your format mask - it begins with 'S'.
Format Model
S
Returns negative value with a leading minus sign (-).
Returns positive value with a leading plus sign (+).
Returns negative value with a trailing minus sign (-).
Returns positive value with a trailing plus sign (+).
Restriction: The S format element can appear only in the first or last position of a number format model.
SQL> select to_number('+1,789.55','S999G999D99','NLS_NUMERIC_CHARACTERS=''.,''') from dual
2 /
TO_NUMBER('+1,789.55','S999G999D99','NLS_NUMERIC_CHARACTERS=''.,''')
1789.55
SQL> select to_number('1,789.55','999G999D99','NLS_NUMERIC_CHARACTERS=''.,''') from dual
2 /
TO_NUMBER('1,789.55','999G999D99','NLS_NUMERIC_CHARACTERS=''.,''')
1789.55Rgds.

Java 7u45 gives spurious warning about missing Permissions attribute

The security dialog in 7u45 gives a yellow warning about missing Permissions attribute.   Does anyone know how to get rid of it?
Same as the yellow box in the screenshots (#2 and #3) documented here (although none of them discuss the Permissions attribute) :
What should I do when I see a security prompt from Java?
The MANIFEST.MF file for the app definitely contains this attribute. There's only one jar for the application, and it's signed.
Might this be another security dialog bug? Or am I missing something? The JNLP contains the same "all-permissions" security tag.
I also found the release notes for 7u45 mention a couple of cases where the dialog might still appear
(see last issue: Java™ SE Development Kit 7 Update 45 Release Notes)
I don't use the JNLPDownloadServlet but my own. I didn't model it on the JNLPDownloadServlet, but guess I could have partly the same issue since I use versioning.
My jar doesn't fail to download though, it's just that its displaying this warning.
MANIFEST.MF:
Manifest-Version: 1.0
Implementation-Title: My app
Implementation-Version: 3.0-SNAPSHOT
Built-By: me
Application-Name: Myapp
Created-By: Apache Maven 3.0.5
Ant-Version: Apache Ant 1.8.2
Trusted-Library: true
Implementation-Vendor-Id: org.me
Trusted-Only: true
Build-Jdk: 1.7.0_45
Permissions: all-permissions
Specification-Title: my-client
Specification-Version: 3.0-SNAPSHOT
Archiver-Version: Plexus Archiver
Codebase: *.me.org

I went the Java version detection applet and I don't get a warning about the applet being blocked in the future.
https://java.com/en/download/installed.jsp
https://java.com/en/download/installed.jsp
I dug the jar for the applet out of my Java cache and it contains Manifest.MF with the following contents:
Manifest-Version: 1.0
Codebase: www.java.com java.com
Created-By: 1.7.0_25 (Oracle Corporation)
Permissions: all-permissions
Application-Library-Allowable-Codebase: www.java.com java.com
Application-Name: Java Detection
Name: JNLP-INF/APPLICATION.JNLP
SHA1-Digest: jPquHTBq5R8txQLe5/T20x70Y7w=
Name: JavaDetection.class
SHA1-Digest: kQNVjPC5Yym1DszdpX1D2EH8Ll0=
The jar contains one Java class and a signed JNLP-INF/APPLICATION.JNLP file that looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="https://java.com/en/download/" href="JavaDetection_applet.jnlp" spec="1.0+">
    <information>
        <title>Java Detection</title>
        <vendor>Oracle Inc.</vendor>
    </information>
    <resources>
        
<j2se version="1.6+"/>
        <jar href="JavaDetection.jar" />
    </resources>
<security>
<all-permissions />
</security>
    <applet-desc
         name="Java Detection Applet"
         main-class="JavaDetection"
         width="1"
         height="1">
     </applet-desc>
     <update check="background"/>
</jnlp>
They are running applet via JNLP:
<applet code="JavaDetection.class" width="500" height="150"><param name="image" value="/im/download/verify_anim.gif"/><param name="centerimage" value="true"/><param name="boxborder" value="false"/><param name="jnlp_href" value="JavaDetection_applet.jnlp"/></applet>
The JNLP file downloaded from here: https://java.com/en/download/JavaDetection_applet.jnlp matches the signed JNLP file in the jar (except for name).
We are still working on getting our applications to not show the warning message but this appears to be an example of where the "you will be blocked in the future" message is not happening. We don't run our applications as applets so if anyone can find another working example that is a more traditional JNLP app, please post a link.

Launching from an applet

Does anyone know if its possible to Launch the likes of a notepad file from an applet?.My problem is that I need to assign a help menu to the applet but it will be considerable length. Can anyone help?

Launching an application from an applet is a security violation. There may be ways around this (signing, JNLP) but there's an easier solution.
You can use the web browser that launched the applet to show .HTML pages. If your help is in text files, open them with Open Office (free DL if you don't have it) and save as .HTML. (Don't, uh, make that DON'T! use MS Word for this. Test MS Word on a copy of a bit of your text if you don't just take things on faith.)
Then launch the .HTML in the browser, this way:
http://java.sun.com/docs/books/tutorial/applet/appletsonly/browser.html

Signed JNLP restrictions

Similar Messages

Maybe you are looking for