Re: Disabling the Sandbox
Roedy Green wrote:
I know I need to sign the applet for distribution, but for development
purposes I'd like to be able to simply disable the sandbox, give my
applet permission to do whatever it wants, even if that means
temporarily disabling all security in my browser/VM/etc.
I think someone said AppletViewer has no sandbox.
Correct. (AV is also used by JWS to launch applets,
and JWS imposes a sandbox, but that is not relevant
to the type of use of the AV to which you refer).
You can make it a hybrid and run it as an application.
Yes. This can be good for simple applets, but might
require more work if the applet actively uses the
parameter map, or opens other URL's etc.
But, I prefer ..
Use an ANT script that does the signing. It takes only a second.
..the Ant solution for this day and age.
After all, it can not only build and sign a project in
a matter of moments, but you can also add an FTP
task to upload the project (applet or JWS app.)
when it is ready for deployment or update!
To the OP. Any of the three methods outlined by Roedy
is better than attempting to decipher those (damnable)
policy files as they might interact with any real world
browser. It might be possible to get it working on your
dev. machine, but is probably not worth the bother.
Since it makes sense to create an Ant script to build
(sign) and deploy the applet, it makes sense to write
it now, and use it during development.
As an aside, even signed applets have 'issues' in IE on
Vista - a new security model limits them to accessing
files from specific directories. If it needs to be signed,
or otherwise 'loosen' that restrictive sandbox for web
deployed apps., I would tend to look to web start*.
* Which, ironically, is also affected by the new Vista
security model, but I /might/ have a fix for that problem..
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via http://www.javakb.com