file:///C:/jack/testing/ui/static/index.html
http://localhost:8080/testing/index.html
https://myserver.com/testing/index/html
Is the javascript that reads those files in the index.html or run from there?
If it's running on a client computer how is javascript that runs on their computer going to download files from the server with a local file system address?
Al Hobbs wrote:I don't you will be able to read the files using javascript. There is another thread with a similar topic about read/write using javascript in a web page. For security purposes javascript doesn't have access to the local file system directly. something like that
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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Yes, JavaScript does have a sandbox, although I've never seen a formal list of its restrictions the way that the ill-fated Java Applet sandbox had.
Some things that applets couldn't do - which are probably also true for JavaScript:
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.
It is possible to sign Java applets - and I believe that this is also true of JavaScript - so that these constraints can be relaxed, but the process is tedious and ugly.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
1. Pretty much exactly this. Although it can be tweaked to not hard-code the filename being copied.
2. JavaScript isn't needed, although if your client webpage wants to be more dynamic it can request the file via an AJAX URL request.
Jack Tauson wrote:I am wondering because user is pressing the Download button, Javascript might be needed? And would I need additional libraries lke FileSaver.js that I have used above in my javascript code?
Sorry, I am little confused here.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Don't get me started about those stupid light bulbs. |