Al Hobbs wrote:The thread mentioning it: thread
I'm guessing the reason it works when you run it from a local html file is because the browser can see that the code is local to the computer based on the url or some other way. When you get the html from a server it can see the url location is not local.
1. Access the client's local filesystem (e.g., erase critical OS files, send a copy of private documents to Bulgaria, implant viruses).
2. Access the client's local printing subsystem (start a print job of 1 billion pages each with a single character on the page)
3. Communicate with servers other than the one that served up the applet. For example, www.botcontroller.com.
Tim Holloway wrote:
Create a file-copy servlet. This is a better approach, because not only can you read files from any place on the server's filesystem that Tomcat has read-access rights to, but you can also edit those files while copying them or even create "files" from scratch to copy. Since it's a servlet, all that's required is to open the source file, copy/modify/create data as neede and output it to the HttpServletResponse output stream along with the usual headers (Content-Type, Content-Length and so on). If you're minded to, you can even pass in the source directory path via JNDI so that it's not hard-coded into the WAR.
1. Pretty much exactly this. Although it can be tweaked to not hard-code the filename being copied.
Sorry, I am little confused here.