In the Chrome extension I am trying to write, I need to talk to a service over TLS. For this purpose, I need access to a CA cert pem file and client cert and key pem files which are on my disk.
Is any of the below possible -
The extension has file upload dialog for each of the file - where the user can 'upload' the pem files once during setup phase. The extension stores them in some kind of storage and uses them to talk to the service.
The user specifies the paths to each of the files on filesystem during setup phase and the extension reads the files from disk when needed.
I have searched on both of these alternatives. For the first one, Chrome's browser storage is not storing a file object, it also has a limit of 8KB per key where the pem contents can slightly exceed that limit. For the second approach, I don't think extensions have access to user's entire filesystem.
Any pointers on how to proceed will be really helpful!
regarding your first suggestion:
You could use the localStorage or the indexedDB of your background page to store the values of the files. They have a greater limit. Although I'm not quite sure, if this storage survives an update.
Regarding your second suggestion:
From a chrome extension, you only have access to the Download Folder of the system via the chrome downloads api. But I haven't seen a way to create a file. So your user may have to put it there himself which may be bad ux.
I personally would try the first way first.
Good luck:)
Related
I'm trying to develop HTML base editor equipped with browsing local files function.
I know basically that is restricted by browser to open local files.
However I found out some method doing this activity.
using path begin from "localexplorer://" it works perfect for English path name.
But when I use Japanese folder name or file name it becomes error.
I tried to convert SJIS format that file names but this is not work.
Here is code.
[![error[![\]\[1\]][1]][1]][1]url = 'localexplorer:' + event.target.innerText;
array = str2array(url);
sjis_array = Encoding.convert(array, "SJIS", "UNICODE");
sjis= Encoding.codeToString(sjis_array);
window.open(url, '_blank');
According to browser security, javascript is only allowed to run in the sandbox, you cannot read or write arbitrary files:
JavaScript and the DOM provide the potential for malicious authors to
deliver scripts to run on a client computer via the Web. Browser
authors minimize this risk using two restrictions. First, scripts run
in a sandbox in which they can only perform Web-related actions, not
general-purpose programming tasks like creating files.
If the user selects a file via <input type="file">, you could try to read the content of the file through FileReader API, like this case: How to open a local disk file with JavaScript?
If you need to interact with files on the user's local device or a user-accessible network file system, you can try to use the File System Access API. And this must be done in a secure context, and must be called from within a user gesture. You can also read this article to learn more about it：The File System Access API: simplifying access to local files.
Thank you for your response, I solved this issue by Forefox plug in extensions, it seems like chrome did not support this functions even if there is plug in extensions.
I'm making an extension that among other things edit a javascript file in an external editor (one on the user's computer). The extension has the javascript file saved in chrome.storage but it will ofcourse be a lot easier for the user to write code in their own editor.
This is why I decided to find something that creates a file on the user's filesystem which the user can find and edit it themselves, and if any changes are made, sync that back up to the extension (either by periodically checking or by using some listener).
I have looked around but nothing really seems to fit what I'm trying to do. Chrome's fileSystem API only works for chrome apps, not chrome extensions and the HTML5 fileSystem API does not allow for a simple filesystem URL to be requested and opened, instead it obfuscates the stored file and makes it practically impossible to edit that file easily.
Something else I looked at which might be more promising is letting the user edit one of the files in the directory where the extension is stored and somehow retrieving that content. This is however going to be a bit tough to implement with chrome's all the hash checking going on in chrome extensions not to mention the general modifying of those files' contents by the extension (possibly by hacking around by specifying your own update URL and "updating" a dummy javascript file that is going to be written to).
Is there any way to simply ask for a location to store a file and then allow the user to edit that file and sync it back up?
No, extensions are sandboxed from the real filesystem.
As you said, it's possible to read extension's own files; however, this is read-only for the extension and modifying those files on a deployed extension will result in Chrome detecting extension "tampering" and immediate disabling as a precaution.
The only way for a Chrome extension to escape the sandbox is, as wOxxOm suggested, a Native Host module. Note that this cannot be distributed in Chrome Web Store with the extension; it needs a separate installer.
Alternatively, you could use some sort of cloud storage with API to access it; e.g. a user could store something in a Dropbox subfolder, and your extension can authorize access to it via Dropbox API. Unfortunately, there is no "native" solution like syncFileSystem for Apps.
I need to modify an XML file from browser which is at local file system and save back at same place where it has been picked from browser.
I have searched a lot in google but didn't find any solution. Please help me on this.
You can read a file from the the local file system, but browsers (and JavaScript) will not ever allow you to save back to the file system.
You have a couple of options:
1 - use cloud storage and avoid the file system all together
2 - Create your own desktop app and wrap a web browser control. Then open/save the file in your own code, and pass it to the browser control.
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.
Is there a cross-platform way to do these actions? Or only open files, the user download the files. I want to make a mmo side-scrolling game, and it needs to save maps, sprites and musics.
It's not possible to access the local filesystem at the client's side. If your data is text (image -> text through base64 data uri's), the DOM Storage may be interesting for you. The files must be base64-encoded at the server's side, though.
References:
https://developer.mozilla.org/en/data_URIs
https://developer.mozilla.org/en/DOM/Storage
JavaScript has no I\O capabilities by itself.
If you want to reduce the traffic use the model in Travian:
the user can save all of the resource files needed to his PC, device etc;
the user submits to the server the path, where the resource files are saved;
the game generates custom css with localpath (the path to the files on his machine).
This will reduce the traffic enormously.