I am building a chrome extension, I want to read and write in the user's disk storage. I want to make folders in users' documents, store screenshots, and delete and read. Is it possible?
I have searched, but could not find a way to do this, I want to know if it is possible, if it is possible, could you tell me, how to do that, or refer to some docs?
Extensions cannot access the file system directly.
(except in very limited ways)
Native Messaging allows extensions to access the file system, by passing messages to and receiving messages from a native application, such as a Python script.
The native application (which you have to program yourself) then accesses the file system directly.
Because your question isn't specific, I can only refer you to the official documentation:
https://developer.chrome.com/docs/apps/nativeMessaging/
Related
I'm developing a Chrome App to allow users to create virtual documents that are stored within the app itself, meaning I don't want the users to have direct access to the files.
The reason why this is is because when the app first starts, it's a screen showing previews/thumbnails of all the created files. If I gave users control over where the files were stored, this could be interferred with by having multiple files in various locations.
What I'd like to do is store everything inside of the app. If possible, I'd like to use JavaScript to create, modify, and edit files within the packaged app, not through the user-accessible file system. Is there any way to dynamically add files and folders to a packaged app using JavaScript?
If not, what are my options for a controlled system in which users cannot move their files to a different directory to keep my thumbnails/previews intact?
You only have read-only access to your package directory.
For an isolated virtual filesystem specific to your app, you should use the HTML5 Filesystem API. Yes, it has a big warning regarding its status, but it's the basis of Chrome's own APIs so it is not going anywhere in Chrome.
You should carefully consider though if it's really the best experience for your users. The good part though, if you ever wish to allow to use a location on the real filesystem, you don't need to change much - the chrome.fileSystem API simply provides another DirectoryEntry, but the rest of working with it is pretty much the same.
I'm working on a Chrome extension to be used as an internal tool. Its required behavior is:
As a page action, enable an address bar icon when looking at certain intranet pages.
when the user clicks the icon, identify all files of a certain media type (say, .jpg) on the page, and
silently save them all to a directory on the user's local drive.
This question has been asked before, but the answer then was "use NPAPI", and NPAPI is now derelict.
So, what is the currently available way to achieve this? The ones I've looked at are:
The chrome.FileSystem API --- but this does not save files in any user-accessible location. Instead the stored files are hidden behind obfuscated names in an undocumented directory. User requires that the files be stored under their original names in an accessible directory.
The HTML5 download attribute, by creating a data: URL and programmatically clicking it. This pops up a "save as..." dialog for each file, which is unacceptable when there are a hundred assets on a single page. User requires that the files be downloaded without further interaction beyond the single icon click.
The Chrome Download API, but that is only available in the beta and dev channels. User requires this extension work with mainstream Chrome.
Use the Native Messaging API by creating a small .exe that simply saves a file to disk, and then pass the .jpg as a blob to it. This seems very cumbersome and I am not even sure how to reliably pass large blobs to EXEs like that.
Is there another approach I can try?
You've done quite a lot of research. Indeed, regular web pages cannot write to the user's filesystem without any plugins or extensions. Also, the HTML5 Filesystem API only provides access to a virtual filesystem, as you've observed.
However, you are confusing the chrome.fileSystem API with the HTML5 FileSystem API. Unlike the HTML FileSystem API, Chrome's fileSystem (app) API can directly write to the user's filesystem (e.g. ~/Documents or %USERPROFILE%\Documents), specified by the user.
This API is only available to Chrome apps, not extensions. This is not a problem, especially since you're developing an internal tool, because you can install the app and extension, and use message passing to communicate between the extension (page action) and app (file system access) (example).
About chrome.downloads: Since your extension is internal, you can probably force users to get on the beta/dev channel in order to use this API. The only limitation of this API is that the files will be saved in (a subdirectory of) the user-defined Downloads folder.
EDIT: The chrome.downloads API is now avaiable in all channels, including the stable branch (since Chrome 31).
I am afraid that you have done your homework, meaning you looked at all possible alternatives.
The best way to achieve exactly what you want, would be (as you mentioned) using a supporting native app and communicating through Native Messaging. BTW, since bandwidth is rarely a problem on intranets, you might find it simpler to pass the resources (e.g. images) URLs and have the app download and save them.
(Yes, it will be more cumbersome than simply developing an extension, but one's got to do what they've got to do, right ?)
On the other hand, if you are willing to sacrifice a little bit of user's experience over simplicity of development, I suggest combining the HTML5 goodies (that allow you to create and download a file locally) with a JS zipping library (e.g. JSZip), so the user only has to download a single zip file (and is only prompted once). BTW, if the user wishes, he/she can choose to always download the files without prompting (but you knew that already).
Use the Native Messaging App idea.
The native app is cumbersome and a pain to write because documentation is poor, and unless you get the JSON formatting exactly correct on both ends you will not see anything in a console because stdin and stdout are taken over.
But, you will be happier when it is done because you can use standard tools (e.g., Windows Explorer, a hex editor, TeamViewer...) to view, move, and delete files, and otherwise see what is going on. Chrome's sand-boxed file system works, but seems to now be a dead-end (no other browsers have picked it up). No one is likely to develop third-party tools for it. Of course you probably don't need tools once everything is working, but until then, debugging is a nightmare because you need to write code (and quite a lot of code) just to track what files are in what directories, file versions, remaining disk space...
Another solution for internal (or may be non-internal) usage is to connect to a websocket server, local or remote.
You can put it in both background.js or content.js (use wss:// for https://)
var ws = new WebSocket('ws://echo.websocket.org');
// var ws = new WebSocket('ws://127.0.0.1:9000');
ws.onmessage = function(res) {
console.log('received data:', res.data);
};
ws.onopen = function() {
ws.send('hello');
};
Is it possible to create something like Google Chrome's Workspaces, but with HTML5, Javascript or some other web based language?
I'm currently working on a web based ide, and I'm interested in implementing something similar to how Google Chrome handles local file editing. Basically asking the user for permission for accessing files in a particular directory that they select.
I've managed to open files that the user selects and show its content, but after editing there's no way to save it back to the same file, short of downloading it every time they save.
Is this possible with current technologies? or would I have to use something like Java?
The Achilles heel of your plan comes from a misunderstanding of the File System API. The most common misunderstanding about the File System API is that it might somehow give scripts direct read/write access to the client's local file system (e.g., C://whatever). As has been widely documented, including in the tag Wiki for HTML5-FileSystem here on Stackoverflow, "the File System API cannot directly access the local file system." The API provide access to a "virtual" file system, not the user's local file system. You cannot, therefore, use the File System API to "ask the user for permission for accessing files in a particular directory that they select," as you're seeking to do for your browser-based IDE project.
The set-up in question:
I have a stand alone, offline, kiosk mode instance of Chrome running on a Windows machine. I have full access to the system and any admin rights. I can start Chrome with any flags set or unset.
The task:
I have been asked to create a log file which tracks user activity within the offline app I am coding. It's a simple form of analytics which will append each event to the end of the file separated with a comma. The file will then be sent to a server once a day via a scheduled task. (None of this is my idea so please don't troll me)
Ruled out:
Any server side code - I have lobbied for Node, PHP etc but as this will be distributed to many different installations so we cannot guarantee this will be installed.
Flash/ActiveX/Java - ideally would like to avoid this (even though these will be installed by default)
Possible solutions:
File API - I have looked at this but AFAIK if opens dialogue boxes to save the data to each file and this needs to happen in the background.
Security - I have read in other SO Questions that this can be achieved if the security settings are reduced but no-one goes on to explain which ones. Is there a simple flag which allows it?
How to enable local file system read write access from Google chrome? - similar question!
Ideal result: (something akin to PHP)
$file = 'log.txt';
$current = file_get_contents($file);
$current .= ",clicked:link";
file_put_contents($file, $current);
Possible ideal side result: proving this isn't possible and forcing PHP/Node/Java to be used ;)
In reply to those suggesting local storage : I'm not storing unique key/value pairs and that is very much like setting a cookie. Similarily there are file size limits.
To those suggesting web SQL such as SQLite in chrome - there are file size limits if it's not a chrome extension. The only way I see that working is if I were to find the location of the file in the windows directory (C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\databases) and upload that from the schedules task. Perfectly feasible but it is not a desirable answer.
You could use HTML5?
http://diveintohtml5.info/storage.html
var foo = localStorage.getItem("bar");
// ...
localStorage.setItem("bar", foo);
You can use the Chrome Apps File API, you will need to grant access to the file via a user action once, but after that you can get access the file again by using restoreEntry
You can use localStorage to save offline data. It's impossible to access other files using Javascript since it's a violation of the sandbox.
From http://en.wikipedia.org/wiki/JavaScript#Security:
JavaScript and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the web. Browser authors contain 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.
You may want to look into Local Storage which is part of the HTML5 spec.
This will only be supported in modern browsers though.
If you need to use older browsers then may still be able to achieve what you're after using dojox.storage
Use HTML5 features like Web Storage or Web SQL database to store your logs.
Whenever needed read logs from the client side storage and send it back to the server & delete the client storage.
Refer http://www.html5rocks.com/en/features/storage.
I'm a first time user, just in the initial stages figuring out if this is going to be useful for me, so forgive any naive questions. I'm using Google Chrome.
Here's my use case -
The user needs to store some information to my application(web based) which may include paths to some files on his system. When the user comes back to access this information via my application, he should be able to click on the links that point to these files on his local disk and open those files.
Now, we know that browsers will not allow this due to security concerns.
I had the following questions
The description for HTML5 FileSystemAPI says that this will allow us to access files from a "sandboxed" section of the users disk.
Does that mean that the files that my user wants to read should only originate from a specific folder on his disk?
Do we get to decide what that location would be? File browser access to Chrome's sandboxed filesystems - i get the idea from this question that chrome decides that.
I would appreciate if someone could throw some light on this. Thanks guys.
AFAIK, the FileSystem API doesn't provide access to files outside the sandbox and the sandbox's location is imposed by the browser. You can use HTML5's File API to let the user upload data, and then store this data using the FileSystem API. However, I don't think this is what you want.
Unrestricted access to a user's filesystem is only possible through a Java applet or another plugin.