This is my html code
<applet code="SignedAppletDemo.class"
archive="SSignedApplet.jar"
width=400 height=400>
<param name=file value="/etc/inet/hosts">
</applet>
Solve that 403 from the server first. Nothing the applet itself does, can sort that.
It seems strange that this applet is in a Jar called SSignedApplet.jar (should that be a single 'S'?), yet you are messing with policy files. Policy files are no good for anything but development. Forget them. If the Jar is signed, the policy file is redundant, you should be seeing a prompt to trust it. If it is not signed, sign it.
Note also that sand-boxed applets can access the local file system using new functionality introduced to applets in Java 1.6.0_10.
Why is this an applet rather than an app. launched using Java Web Start?
Note also that sand-boxed applets can access the local file system using new functionality introduced to applets in Java 1.6.0_10.
Really??? How is it possible in Java 1.6?
I have been thinking that accessing local file system is always restricted so we must sign or add permission to the applet.
Note also that sand-boxed applets can access the local file system using new functionality introduced to applets in Java 1.6.0_10.
Really??? How is it possible in Java 1.6?
I have been thinking that accessing local file system is always restricted so we must sign or add permission to the applet.
You have not kept up with the times.
See the last two links under the 'See also' section of this applet info. page. For a demo of the abilities for accessing the local file system (in a sand-boxed app.), see the File Service demo..
I think you are confusing between Applets (they are embedded in web browsers) and Java Web Start JNLP (java programs that are downloaded on client computers and being executed as normal java programs).
Unsigned applets cannot perform the following operations:
They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.
They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).
They cannot load native libraries.
They cannot change the SecurityManager.
They cannot create a ClassLoader.
They cannot read certain system properties. See System Properties for a list of forbidden system properties.
and:
Signed applets do not have the security restrictions that are imposed on unsigned applets and can run outside the security sandbox.
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32769
posted
0
Nam Ha wrote:
Note also that sand-boxed applets can access the local file system using new functionality introduced to applets in Java 1.6.0_10.
Really??? How is it possible in Java 1.6?
I have been thinking that accessing local file system is always restricted so we must sign or add permission to the applet.
While signing or changing permissions is not required for JNLP, the user must still consent to the action explicitly. So the principle still holds, even if the technicalities have changed.
Nam Ha wrote:..I think you are confusing between Applets (they are embedded in web browsers) and Java Web Start JNLP (java programs that are downloaded on client computers and being executed as normal java programs). ...
I think you are wasting your time, my patience, and the OP's bandwidth.
The last is the one that is a sand-boxed applet, but still can open local files. (And yes, I developed all 3, so I have no confusion about the distinctions between them.)
The knowledge to not make silly statements like the one you did, was contained in the links in my earlier post that you apparently ignored or misunderstood (and I also wrote the blurb to which I linked). I suggest you make sure you understand them, before making further comments on related matters.
Andrew Thompson
Ranch Hand
Joined: Aug 05, 2010
Posts: 59
posted
0
Ulf Dittmer wrote:
While signing or changing permissions is not required for JNLP, the user must still consent to the action explicitly. So the principle still holds, even if the technicalities have changed.
The user experience is quite different.
The old way demanded 'all or nothing' permissions before the applet ever appeared. If refused, it was hard to get another sight of the dialog that prompted us to allow it.
The new way asks permission only when the user goes to use that functionality, and only for that functionality. So the user selects the `Open File` menu item, and sees a warning to the effect 'The app. has requested read/write permission for local files'. Since the user selected the menu item, this prompt is much easier to understand, and more likely to be approved. Further, they can refuse it as many times as they like, and still produce another prompt by selecting 'Open File' again.
0
