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.
Related
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/
We are currently looking at porting a enterprise silverlight application over to html5. The major roadblock that we have hit is the ability to open files from the user's local disk. Currently they have a document library which just links to files on their computer that they can open from within the app and view or print out. All that I read is that you can only access the local sandbox of the web app with the html5 file api's. We want to load these files from code.
Does anyone know of any workarounds to this?
Thanks
There is no way for html5 to access local file without user selection. But FSO: FileSystemObject works for IE and MAYBE could be regarded as a work around. But still there are some requirements to meet.
It is possible to use chrome's filesystem API to access files on a users local filesytem. So you'd have to be willing to make this a chrome only application.
Using java you can create a "Signed" applet which has access to the local filesystem. (if the applet is signed you can request filesystm permissions)
then there is a tutorial for accessing methods of your java code directly from javascript here: http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html
you should be able to perform something similar from silverlight.
There is no workaround in pure HTML5/Javascript. You need the use of plugins, such as Java or Silverlight (maybe you shouldn't port it after all). As for workarounds, HTML5 gives you an easy way drag and drop multiple files that you could transfer on the server and then display back to your users. Another workaround would be to install a custom agent (a software with only a tray icon) that would send the information about the current user "document library" to server and then again, you could display it back to the user.
Note: I've heard somewhere that browsers will eventually stop supporting plugins. http://www.howtogeek.com/179213/why-browser-plug-ins-are-going-away-and-whats-replacing-them/
Ya, I agree with Markain. However, if you were to limit your audience solely to chrome users, I daresay, you would most likely use some of your users. If Huazhihao is right, then your number of leaving customers should decrease but users who regularly use firefox won't be happy. Overall, I think that this will not work. Otherwise, there would be too many websites that trashed your hard driver (or at least wherever you have the rights to edit/delete files). I think it would be best if your product was setup to synchronize the file whenever an internet connection was detected and a change was made to the file. That way the user would not need to visit the website whenever the file was uploaded. If this is some kind of an error file, then it would be most beneficial if you were to make a link in the application that when clicked, would upload the file to the website and the website were to do whatever was necessary. If this is a purely online thing, then I don't see what business you would have looking through other peoples' files =-). Hope I helped!
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.
i have some HTML files that i want to run in user local machine ( offline).
is there any method to find out in which hard drive the program files folder is located?
Note: do you know any methods that don't raise security problems.
I think this question is very confused. Not every computer has a "Program Files" directory or even the concept of drives because not every computer is Windows.
On top of that, HTML5 Offline Mode just requires a manifest file to be hosted by your web server. The browser will put the cached data in the right place for it.
If you're talking about some internal deployment of a non-hosted page and want to spawn IE directly, I think it's a bad idea, but use the %ProgramFiles% environment variable.
There is a file system api in HTML5 - have a look at the draft documentation
If you're calling requestFileSystem() for the first time, new storage is created for your app. It's important to remember that this file system is sandboxed, meaning one web app cannot access another app's files. This also means you cannot read/write files to an arbitrary folder on the user's hard drive (for example My Pictures, My Documents, etc.).
So if you're thinking about a web page being able to poke around a users program folder, then the answer is no, you'll need some kind of an app engine - e.g. Adobe Air or the Windows8 Metro apps.
Basically there is no crossbrowser way of doing this. If it is ok for you to have an Internet Explorer only solution try to look at the ActiveX component called FileSystemObject and its GetSpecialFolder method - http://msdn.microsoft.com/en-us/library/aa265315%28v=vs.60%29.aspx
I'm not on Windows but it seems you can try something like this:
var WshShell = new ActiveXObject('WScript.Shell');
Response.write("ProgramFiles envioronment variable is set to:\n\n" +
WshShell.ExpandEnvironmentStrings('%ProgramFiles%'));
Program Files are found on Environment Variables, so that's what you're looking for.
Regards,
PS: this will lead you to some security warnings. Actually, this is not safe.