Tamas wrote: > Theoretically I agree, however, this restriction is quite unfriendly and > reduces the usefullnes.
Tamas, These security restrictions are placed upon *all* applets. They are enforced by the Java Virtual Machine. They are independent of Jmol. > For example one cannot create (easily) tutorials which could > be distributed > on CD or downloadable as a zip file. If the applet arrives from the web > server, only > predefined files from the server can be loaded. If started locally only > the files from > the same folder can be used, as the load command intentionally does not > understand paths > in names. Therefore arbitrary local files cannot be loaded, or must be > copied to the > applet's folder... Is it necessary to start from the assumption that the > jmol applet is a > potential malicious piece of code? Unsigned applets are designed to be downloaded from the web and incorporated into a web page without any intervention from the user. Therefore, they are assumed to be malicious. This applies to all applets and is not specific to Jmol. > From this respect the plugin solution > is better, even > if it must be installed by the user. (A plugin cannot be malicious?). > Maybe it would be > good that when locally initianting, the applet could read relatively > downwards the > directory tree, but not upwards (so absolute paths and ../ are not > allowed, but > ./fee/foo/this.mol yes) > By the way, this behaviour should have been documented. You are probably right ... we need some better documentation for people who have never used an applet before. Miguel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
