I created a prototype about a tool that would analyze source code and write metadata about it in files to be read by a web application served locally.
Now I need to specify details about how I'll implement it. The data would need to go both ways, first the backend write to file and the frontend read from file, second the frontend write to file and backend read from file.
My question is about how I do the second part, saving from the browser to local files, knowing that I will be serving the page locally.
I've found this api https://web.dev/native-file-system/ that might be what I need, but it's pretty new and requires permission from the user. I guess I can do it differently because I'll serve it locally.
For more context, here's the video of my prototype
Related
I'd like to use html+css+js to create an interface for setting up a simulation. The interface is used to create a visualisation of the simulation, and an output parameters file, by using several input files.
This web-page does NOT need to run on a server and is only run locally on the same machine.
I understand why a sever page is not allowed to access a client file, and that a server page may access another server file. Is it possible for a LOCAL web-page to access a local file?
It is possible to view the contents of any file using file:///path/to/file.txt so I presume that it is somehow possible to pull the result into a running page in the form of a string. However I'm having very little success.
If it is possible please could you detail a simple example of how the contents of a txt file could be read into a string?
Thank you very much
node.js is a javascript implementation that can easily do such things because it is a process running on the machine. A web page is running in a browser which does not have access to the file system, so that would not be possible, however you could bundle your web application into an electron application which would be able to access the osand file system, so while it would use html and javascript it would still require an installation.
If you are using Chrome, you can launch it with the --allow-file-access-from-files flag. Then you can do:
fetch('file:///path/to/file.txt')
.then(function(response) {
// do something with it
})
As the title indicates i want to have a certain application get access to the local file system. To describe why i will illustrate my situation:
I am a running a IIS WebApplication with the C# MVC 4 Framework as backend module. The site solely consists of HTML, CSS markup and some JS. The page will be loaded in IE11+ (Edge) only. For the standard procedure of displaying and accessing data from as well as sending data to the server this works quite fine.
On a certain page I want the user to be able to upload a file using a simple file dialog, like the one you can initiate with a simple <input type="file"> tag. I also want to offer the posibility to download files from the server but need to know where files has been saved / will be saved to.
As described on a lot of different websites, just like this one here, the HTML5 File API does a great job but will not be able to return the full qualified filename including the local path directions, same for JS accessing the file object.
As my research confirmed HTML5, JS and also SWF (Flash) will not report detailed information because they are all sandboxed applications or restricted by RFCs. I already unterstood and appreciate the effort to secure my trips to internet.
But in this case do need the paths where a file was upload from and the file has been downloaded to.
So my question is, what is the best way to expose the full path directions for a up- as well as downloaded file to report them back to the server?
Is it possible to embed a SWF object inside HTML which will run inside an Adobe AIR sandbox or is a signed JAVA Applet still the one and only solution to accomblish this security breaking task?
A solution i would also apreciate would be the possiblity to ask the user to get access the file system, like you grant access to the web push service to receive notifications.
Also if there is a possible solution which may suite my circumstances please let me know by adding some simeple examples / revealing some factful links, thanks in advance.
I have a Django web application that requires accessing audio wav files. I have a file server containing the wav files which is mounted onto my web server which stores my web application files. I then downloaded the files onto my local filesystem so my web application can access it when I'm developing it locally.
My question is about how to access those files from my web application on production versus local. I'm thinking in my Javascript I'd need to have two different configurations that check if my web application is in production or development. If in production, I'd use the path to the mounted file server, and if in development, I'd use the path to the local filesystem on my computer. Does Django or Javascript provide a way of doing that somehow? And is this the right way of approaching getting files from the web application?
The other option I can think of just uploading the wav files along with my web application to the web server so I can access it locally on production and not have to access it from the mounted file system, but I'm not sure how this affects performance and that might cause headaches of having to upload the files every time a recording gets added or removed.
Would that approach be better or would the first approach be better?
Your goal is that users can listen to the audio files when they are using your web application. This is mostly not Django specific.
I recommend that your Django project should have a setting, for example settings.AUDIO_FILES_URL that points to the place your audio files are served from. It might be convenient to use a context processor to add that setting to your template rendering contexts as AUDIO_FILES_URL, or you can do it explicitly. It's a good convention to include a trailing slash in the variable's value (that's how STATIC_URL is usually used.) Set the value correctly in each settings file, whether test or production.
Then in your HTML template you can build a URL for a particular audio file. You might do something like this:
<span data-audio-file-url="{{ AUDIO_FILES_URL }}{{ audio_file_path }}">{{ audio_file_description }}</span>
Finally, your JavaScript code can read the url and create whatever interface you like. Notice that the javascript doesn't need to know whether it's a production system or not. (You could instead avoid javascript and make an HTML5 audio element, if you like.)
In production, Django should only know the base url for the audio files, it should not be involved in serving them. Serving them is something you need to configure the web server to do, i.e. Apache, Nginx or whatever you're using. You could even serve the files from a different host - perhaps making your file server also a static file web server.
Also, I think it would be kind to your users to serve .mp3 instead of .wav!
I am working on project for desktop application. I am using Qt controls with visual c++.
I am loading an html file in the QWebView as,
m_pWebView->load(QUrl("../../../demo/index_Splash_Screen.html"));
Now, what i want is, say, I have some .zip files in my location "c:\demo", I want list (or array of file names) of the files present in that directory.
How can i do this through javascript ?
PS: I went through this link, but it didnt match my requirement. I have not worked with of html, javascript and jquery. Please help me.
I'm afraid you cannot access local files or directories using javascript due to security issues.
Edit: I hadn't thought about the file api so thought for a moment this might not be true, but without some user input to give permission, this still cannot be done.
This question has a good response from PhilNicholas:
I'm afraid I may be the bearer of bad news for your design: The action
you are requesting expressly violates the security model as specified
in the File API spec. The client implementation of FileReader() must
make sure that "all files that are being read by FileReader objects
have first been selected by the user." (W3C File API , 13. Security
Considerations: http://www.w3.org/TR/FileAPI/#security-discussion).
It would be a huge security risk of browser scripts could just
arbitrarily open and read any file from a path without any user
interaction. No browser manufacturer would allow unfettered access to
the entire file system like that.
Thinking about it however, if it is all being run locally, you could use ajax to query a server side script that could return the directory you request.
If it is a Windows application then you could access the local filesystem by using ActiveX objects. You might have a look at this link Reading a txt file from Javascript
Note that activeX usage is possible only when using IE as browser/engine; I used to need it a while ago for developing an HTML application (.hta files).
I'm testing some of the new JS filesystem abilities, i.e. creating an empty text file in the local filesystem. I'm running the HTML & JS files from a local path (file:///). For this purpose I launched Google Chrome with the --allow-file-access-from-files flag from the CLI. The filesystem request is PERSISTENT (and works).
I have read up on different posts about the filesystem, copied and modified some of the code in the tutorials; When I launch the HTML file, my custom success/ failure messages are outputted in the console;
This is the result:
Opened file system:/ // this is the root path of the JS Filesystem.
/wtf.txt // this is the name and path of the text file I created+ it's a success
However, when I look at my directory's (both system and application root), there's no .txt file with the name I assigned to it. How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)? What does it mean that the FileSystem is a 'sandbox'? That I cannot access the (virtual?) contents of it on my local drive, but only with JS? If this is the case, is there a way to prompt the user to save the file?
Thanks in advance for your answers
It seems you're expecting the File System API to work locally similar to an OS file system. The client doesn't work like that. In fact, and API is designed to be your interface, as a programmer, to the files and directories -- the client itself (e.g., Chrome, etc.) will handle the rest on the local level. The API is not designed by which you can create a file via the browser and easily access it via the operating system.
How can I know where Javascript really wrote this file? In what "root" (since the 'root' cannot be assigned)?
Technically speaking, each client can store locally as it chooses. So while you can go to the local file system to look for the file, something is wrong with your approach if you're attempting to do so; the File System API is not meant for that. To your question, you can assume that if there's content the client's storage area (e.g., for Chrome it's something like "C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\File System\") then you can assume that the JavaScript wrote it. But again, it's not set up for user friendly browsing on the local system.
What does it mean that the FileSystem is a 'sandbox'?
Sandbox simply means an area created and set aside for a specific purpose, outside of which the client cannot see/access. See this from Mozilla: https://developer.mozilla.org/en-US/docs/WebGuide/API/File_System/Introduction#virtual
That I cannot access the (virtual?) contents of it on my local drive, but only with JS?
That is correct, and by design.
If this is the case, is there a way to prompt the user to save the file?
If I understand your question right, you're asking if there is a way to provide a specific file to the user and have it prompt them to save it locally. Well, of course if you provide a link to the file (or push it, a different discussion) then the client will prompt the user to save/store it if their platform allows them to do so. But you have no control over where they save it locally nor can you later get it it. If I've misunderstood your question, comment below and I'll follow up.