> Setting:
> "C:\Users\ %username%\.java.policy"
> To:
> grant {
> permission java.security.AllPermission;
> };
> Allowed getURL to work OK on both IE and FF3.
> This tells me: stop being lazy and properly sign your applet, EVEN IF you
> are only
> in the early development/learning stages.
This seems OK for local development but not for a decent attempt to
widely deploy a Batik-based applet, i.e., obligating users to make
such configuration is 1) bad for obvious security issues 2) less
experienced users won't even able to do it.
AFAIK, the main issue may be located in the sample applet's code
itself - I recall Thomas Deweese has previously stated that the
sand-boxing (which provokes this issue) resides in "setDocument" [1].
Avoiding using this API method can help towards avoiding the special
permissions and therefore running with default applet permissions
(which should be more than enough to perform remote requests).
Is it possible avoid creating the new BridgeContext "setDocument"
seems to? Default applet permissions should be enough for most useful
operations such as opening sockets (getURL/postURL) and parsing XML
(parseXML), commonly used in SVG-based smart clients.
Regards,
Helder Magalhães
[1]
http://www.nabble.com/Problem-calling-applet-method-from-script-in-svg-file-td12479719.html#a12611810
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
