Databases
StackOverflow2013
Postsdbo
POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
    primarykey
    data
    text
    <p>I'm the author of <a href="http://www.wordle.net/" rel="nofollow">Wordle</a>, one of the few surviving Java applets in the wild.</p> <p>Recently, I received user reports of warnings that my (signed) applet would soon be blackballed by the JRE because it did not explicitly specify a "Permissions" attribute in its manifest. So, now the MANIFEST.MF <a href="https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias" rel="nofollow">correctly</a> specifies</p> <pre><code> Permissions: sandbox </code></pre> <p>and the <code>&lt;applet&gt;</code> tag includes the magical</p> <pre><code> &lt;param name="permissions" value="sandbox" /&gt; </code></pre> <p>param, as <a href="http://docs.oracle.com/javase/tutorial/deployment/applet/html.html" rel="nofollow">documented</a>.</p> <p>Now, folks who have bent over backwards to install the OS X JRE 7 can run Wordle with no difficulty, but folks (like many school IT admins) stuck on JRE 6 cannot run the applet at all; they get </p> <pre><code>java.lang.SecurityException: JAR manifest requested to run in sandbox only: http://wordle.appspot.com/j/v1390/wordle.jar at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:106) at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:84) at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:319) at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:280) at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:270) at sun.plugin2.applet.Plugin2Manager.isAppletSigned(Plugin2Manager.java:3289) at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:3207) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1536) at java.lang.Thread.run(Thread.java:695)` </code></pre> <p>The symptom suggests that the Java 6 plugin assumes that the signed applet should run in <code>all-permissions</code> mode, and thinks that the request for <code>sandbox</code> in the manifest is an error. It ignores, in other words, the <code>permissions</code> param in the <code>applet</code> tag.</p> <p>Does anyone know of any way for me to help my users other than setting the applet to run in <code>all-permissions</code> mode? I'd prefer to stay sandboxed, both because I don't want people to be afraid to use Wordle, and because I don't want to create an attack surface.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. UShqcasanova
    1. USJonathan Feinberg
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COJust an idea, maybe it is possible to check the java version of the client, and deliver the appropriate version of your program (with `permissions` set accordingly).
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. USUooo
    2. COI'm hitting the same problem with my applets -- Currently I'm testing to see if variations on the possible manifest attributes can help at all. Currently (getting this same error) I have: Permissions: sandbox Application-Name: eMusicTheory drill Codebase: *.emusictheory.com Sealed: true I'm tinkering with Trusted-Only: true and other tweaks, but I suspect this bug can't be worked around, and I'll be forced to serve the applet with full permissions for pre-10.6.8 OS X.
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. USRob Whelan
    3. COAnother idea -- instead of putting the permissions param in the applet tag (as we both are, I believe), what about launching the applet with a JNLP file? This might take a sufficiently different path through the plugin code that Java it will bypass the broken code.
      singulars
      1. POJava applet security model incompatibility between OS X JREs 6 and 7: any workaround?
      1. USRob Whelan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload