I am using ExtJs for front end development and I am looking for a way to set the destination for a file to be downloaded. I know I can use xtype:filefield to browse files, but that requires me to select an actual file, I just need to select a folder for the file destination and then send that path elsewhere. Any way I can do that?
You will not be able to choose the user's download location with javascript. This can only be set from the user's end, otherwise it would violate user's security.
If your app is for an intranet only there are various ways you can push a config onto the user's browsers (depending on which web browser they are running in the intranet). But that would make ALL downloads go to that location.
Most browsers also have a configuration that allow the user to define a location for every download as covered here and here's more specifics for different browsers. The user would be able to (and have to) select the download location for every download.
If this is for an intranet app, and if your intranet is running Firefox, there is also this add-on. You would have to push it out to all your user's computers (or manually install it on them all). I haven't tried it yet but I was planning on using it should a situation like yours arise (all my ExtJS work is for an intranet running Firefox - I push out things like this using a logon script whenever a user logs into the network to automatically install them).
Related
I've built an online photo tagging tool that has a low-res mirror of what is on my local laptop. I'd like to find an easy way to display the high-res version of a given image from my local file system.
Currently I have to get the image name from the web tool, paste it into Lightroom's search system and view that way. I'd like to be able to pull up the high res version, either in the browser or another local app, with a single click.
Options I've investigated:
HTML5 File API/FileReader()/fetch()
These cause even more friction than going to Lightroom, as the user has to select files via the OS file selector and the image directory structure is complex.
Configure local web server to host disk-based images
I've looked at hosting the local image directory with a simple web service, but would need to configure HTTPS to prevent cross-zone violations, and that's more client-side config than I'd prefer.
Any solution that would allow me to reference a local file path directly would work, but modern browsers have (rightly) eliminated most direct paths to local file access.
I'm wondering if there is a way to ask an app on the client side to open the file, in the way that browsers will prompt you for permission to open Zoom and join a meeting, or open a link in the client OS app store. If I could find some way to tell Lightroom to open the specific image without having to copy/paste file names, etc.
This question already has answers here:
How to resolve the C:\fakepath?
(13 answers)
Closed 3 months ago.
After selecting a file in Chrome I need to get the full client side path to that file. Currently, the only path I get is something similar to:
C:\fakepath\some_file
All my googling lead me to the following answer: "you can't because of HTML5 security spec. Besides, why would you need to? You can upload it just fine without knowing the path."
This is a perfectly fine and valid answer except that I don't need to upload the file. The website I am managing can have any number of administrator users that configure the website by browsing for and storing paths to a large number of files. All these files are stored on shared network locations that the web server has access to.
The whole point of this is to eliminate upload time, to prevent the need to re-upload the files if the admins decides to change them and to keep the web server storage space to a minimum. Obviously, the web server also processes and manipulates these files. These are all client requirements.
The web server and the shared locations are all on an internal network not connected to the internet. Also, only the users with admin role have access to said locations and to the web pages that allow them to configure these paths. Security wise, this is enough for the client.
We've been using Internet Explorer and by adding the website to the trusted website list it worked just fine but now users are switching to Chrome, the new official and approved company browser. Internet explorer will soon be phased out.
Currently, users are copying and pasting the path into the input field but they want to be able to browse for the file as they did before.
How can I force Chrome to show me the actual file path, is there any equivalent to the trusted websites list from IE or how would you adapt the website to work with these conditions?
For security reasons browsers do not allow this, i.e. JavaScript in browser has no access to the File System.
You could build a chrome extension, see https://developer.chrome.com/docs/extensions/reference/fileSystem/
You can also open chrome with the flag --allow-file-access-from-file, see https://cmatskas.com/interacting-with-local-data-files-using-chrome/
The FileSystem API gives you a sandboxed file system created just for your web app.
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');
};
Please hear me out before you start crying security issues.
This is for an intranet application, hence I have full range to install any plugins or change any security permissions to suit.
What I want is for them to go to a webpage and click a link to download a file, such as a Word Document. This gets transferred to local storage of some kind (sandboxed if need be) and then is opened in word as a regular file.
When they click save, JavaScript or something will pickup the file is saved or the program is no longer accessing it and can be actioned upon, such as uploading back up to the server.
Is there any way to do this. I have looked at IndexedDb, WebStorage, HTML5 FileSystem API but I am new to all and don't see a way to do this.
I am open to coding any needed plugins as long as you don't mention Flash. The main issue I am coming across is opening a file downloaded into some form of local browser and then opening it via a desktop application, e.g. Word.
Any help, greatly appreciated.
After much research the only way to do it is with a plugin. IndexedDB, FileSystem API or WebStorage can not access the local file system. Which is good.
Silverlight is a good option for intranet and .NET, which is what I have chosen to go with.
Silverlight 5 in full permissions with a file watcher. The file watcher can be accomplished with this method: Is there an alternative to accomplishing what the FileSystemWatcher does in Silverlight?
Is it possible to make user open a file on network BUT DON'T ALLOW them to save it?
When I Filenmae, i get options to Save or Open a file. I don't want users to save that file, they can only OPEN them and read/edit them.
Regards
This is handled by the web browser, not by code. In this case they're hitting the file system directly rather than a web server (so there's no place to override headers or anything like that) and the browser is acting accordingly. I'm thinking the only way to achieve what you seek is to configure the browser to always open the file in the associated program rather than prompt the user. If you're talking about a lot of web browsers, that could be a pain.
Also, since it's opening the file from the user's local file system, they can still save it. Once it's open in the associated program (in this case I'm assuming MS Word), they can save it from there. The only way to "not allow" them to save it in this case would be to remove their write access to the file at the OS level (I'm assuming Windows). This also assumes they don't have administrative rights. Otherwise, you'll want it on a file share on a server or something where you can control access.
But even then, they can just save it locally somewhere else.
It's not possible, unless you also make them open some other program that hijacks the basic saving/opening functionality on their computer.