This is new to me since I did something similar a few years back:
<input type="file" onchange="fileSelected(this.value)" />
This will provide a fakepath reference, IE, if I select test.jpg on my desktop it returns:
c:/fakepath/test.jpg
My problem is, I'm developing an online application that lets clients design a page, that is, they select images, drag them onto the page etc.
My design ideally would be they select local files (that could be big in filesize) so there is no uploading involved immediately, I keep an array of the paths of the files and then at the end of the design process it saves the media and the positions of elements to the server.
However, fakepath is preventing me from doing this!
Do I have to upload the files each time? This would significantly slow down the design process.
However, fakepath is preventing me from doing this!
This is a security feature (see related SO questions). Even if there were a real path, you would not be able to add the file path to the upload control programmatically later. AFAIK it's not even possible with Flash uploaders any more.
You will either have to use/build a Java Applet or ActiveX control (yuck!), or in fact actually upload each file.
Related
I'd like to have a way for a webpage -which is generated dynamically by my server- to read all the files in a specific user folder, manipulate them using javascript, within the web browser, and using them to show to the user some results (specific correlations between the data, dependent on the context and sometimes some graphs, drawn using these correlations).
Communication with the server about these data is neither required nor desired. Actually, since all the manipulations needed can be done via javascript and the files can be huge, for now I absolutely don't want that their content is uploaded to the server. Therefore there are no security risks (at least none that I can see).
Server side, I'm only interested to save the name of the folder, so that the user (who is registered) doesn't need to select the files one by one or to select them again every time a new page is dynamically created.
For now, the only hopes to find a solution that I have been able to gather are about using the Chrome FileSystem API (but I'd prefer a general solution, not dependent on a specific browser) or creating an extension that the user should install to use this feature when visiting the website (which, for me, is maybe even worse than relying on a specific browser).
So I wonder if there is a way to implement this feature using only pure javascript and HTML5 and using neither extensions nor browser dependent solutions.
Due to security reasons, JavaScript running in the browser should not be used to access the filesystem directly. But definitely you can access it using Node's fs module (but that's on the server side).
Another way is, if you let the user pick files using the <input type="file"> tag then you can use the File API to fetch the contents. But I think that is not what you are looking for.
Recommended reading: https://en.wikipedia.org/wiki/JavaScript#Security
I would like to create a Node-Webkit app but avoid redistributing the font files. I have thought of a few approaches. I am considering the model used by hosted font solutions where a temporary URL containing the font file is hosted.
I have a way to encrypt the font file. You could convert the font to base64 assign it to a local variable in a javascript library with closure. The javascript file is compiled to binary and cannot be read by the end user.
Setting the base64 value to a style property would potentially expose the font as a base64 value to the DOM. What I would like to do is create a temporary route to the font file that I render from the private base64 value then remove the route once it is accessed. I can see how to achieve this as a node.js app but I'm new to Node-Webkit and don't see any documentation on router.
It seems like the hosted font solutions allow a one-time access to the font files so users cannot download the files. So does Node-Webkit have the capability to perform routing?
First things first: welcome to the internet, you can't prevent people from using the data you send them. Either you don't send them data, or you accept the fact that once the data is on their computer, they can do with it whatever they like (if you want people to be able to connect to your content through a browser, the browser needs to download and decode the content, which means that you cannot stop distribution, and in fact you are a distributor in this scenario).
Even if you tie the font loading to a session identifier (e.g. your user has to hit the page URL first, which sets a cookie value, which is then checked when they try to download the webfont in combination with the IP for which the cookie was initially set) they only need to download your font once to trivially have access to it and do with it what they want. It'll either live in their browser's cache directory, or it's accessible via JavaScript (by mining document.stylesheets for instance) which means it's trivially converted to real data and saved to disk (e.g. a window.open with a binary mimetype causes browsers to pop up a save-to-file dialog).
There, I just downloaded your fonts despite your best efforts: if you can send me the data, and the technology we've chosen for that exchange is HTTP(S), I will be able to access that data, no matter how much you further restrict how or when I can get that data. I just need to get it once.
So: don't focus your efforts on the how or when. Take the given that your users will have access to your font(s), even if only once, and instead focus your efforts on what they can do with your font(s) once they do, because that's far more important. There are several things you can do to make sure that what you distribute is mostly useless outside your content. For instance:
Don't use full fonts, use subsets, so that your users only get partial fonts containing strictly those glyphs that are needed to render your own content. This severely limits what others can do. You can take this as far as you like, serving dedicated subset fonts per page, or even per section of a page.
Set the fsType flag for your font(s) to not allow installation. That way people will get your font(s), but they can't further use them except on the web
Make sure to properly mark the font(s) license in the font itself, so that if people do use your fonts, you have legal recourse and can sue them for circumventing your license outside the "personal use" context.
However, if you also want to take advantage of caching, you don't want to do (1), and (2) and (3) are enough to give you a legal basis to go after people who use your font(s).
Bottom line: preventing users from "getting" your data is a waste of time. It's the internet, your users getting your data is entirely the point of the technology. Instead focus on making sure that what they get is useful only within the context of your content.
After all, if TypeKit can make this work, so can you. (Which would be an additional recommendation: don't roll your own solution if you can make use of an established existing solution. Are the fonts available through Typekit or the like? Use them instead and save yourself the trouble of reinventing the wheel)
You could encrypt it and then decrypt it with node native methods for that matter:
http://lollyrock.com/articles/nodejs-encryption/
Also you can zip all your assets into one file and rename it to "package.nw" and the chrome executable will run it (I know this is not a reliable security measure) plus with that file you are able also to merge it with the nw.exe file there you'll end up with only one file that is the executable, so the regular users will not be able to see your files and your package.json file is somehow protected thus preventing users from changing the configuration and seeing your files/assets.
https://github.com/nwjs/nw.js/wiki/How-to-package-and-distribute-your-apps#step-2a-put-your-app-with-nw-executable
Context:
I'm a TiddlyWiki (an offline non-linear personal notebook) user, and I would like to improve the workflow of image attaching. The basic way to attach an image to a TW is to write stuff like this:
[img[image-url-either-absolute-or-relative]]
in the edit area. The issue is, if I have 20 images I'd like to attach, I have to extract 20 urls and paste them (and surrond with the [img[...]] wrappers). My idea is to write a plugin that would allow me to drag-and-drop the 20 files from a file manager to the editing area, and get 20 urls (better wrapped with basic [img[...]] syntax or some other).
Is this possible?:
Getting a url (or uri, whatever) of a local file isn't a usual operation for web applications, and for security reasons it seems to be forbidden (at least by default). Still, is there any way to imlement this? Provided that the user will accept any security warnings.
May be workaround?
If there's a possibility for a workaround (may be using AutoHotKey or smth else), I'll be glad to hear (keep in mind that the goal is to improve the workflow, so minimum of additional clicking/keypressing is desirable).
Currently, I would love to implement this for Window 7 + Opera 12.17, but of'course the more general the solution is, the better (in the end, I'll share that with others if it's that useful). And yes, currently I'm talking about TW Classic, not TW5.
The approach for doing it with a copy operation has two phases:
First, you use the HTML5 support for drag-and-drop upload 1 [2] to the get file into the browser.
As the page I linked demonstrates, the HTML5 File API provides you with the filename (without a path), mimetype (possibly guessed), size in bytes, and contents. (The API spec also shows a field for last modified date)
The second step is then to get the file back onto disk in a known location relative to the TiddlyWiki file and insert a relative URL at the current cursor location.
TiddlyWiki has a collection of different saver backends it uses, so you basically want to hook in and use the same API TW Classic uses to write the backup file and optional RSS ChangeLog.
Note: This may or may not yet be available in TW5. I remember seeing re-adding backup support as still on the roadmap and, judging by savers/tiddlyfox.js, it seems to currently hard-code the path of the TiddlyWiki itself. However, saving them within the Wiki as binary data tiddlers is always an option.
As for doing it without making a copy...
I get a pretty strong impression that it's not possible to do it perfectly for security reasons, but here are some ideas:
If you are willing to either manually type the path or guarantee that the files will always be in a known folder, you could use the File API to retrieve the filename only.
You could write a script or plugin which implements this workflow:
Copy the file in Explorer
Position the cursor where you want the URL
Press a global hotkey
As someone who moved to Linux years ago, I'd use Python+PyGTK+python-xlib but AutoHotKey is GPLed and should allow you to do it on Windows:
It can bind a global hotkey
It can read the clipboard
If you can't find or write an AHK clone of Python's os.path.relpath and urllib.pathname2url, you can call an external script to do the work.
It can fake keypresses, allowing it to auto-type into your TiddlyWiki's edit window.
Objective
I am creating a web application and have been looking for an async file upload solution other than iframe and form support.
Browser Support
I am fully willing to exclude everything but IE9+. IE tends to be the browser I have the most trouble with.
Goal
I have a table and I want to be able to click on a link, show a file dialog and then upload the file immediately after selection. No page refresh.
More specifically I am trying to figure out how Trello does their file uploads. After looking through the javascript, I found that they bind the the file input to an on change listener, but after that I can't see what they are doing. Im under the impression that they use websockets with node.js to transfer data, but after doing a little research, most people say that websockets wouldn't be good for that. Trello blocks all versions of IE except 9 and 10 so I looked into HTML5 File upload think that may be a solution. However, after some research IE9 does not support the HTML5 File API.
Question
So finally I am looking for some way to upload files without the iframe and form solution. Can someone list the possible methods I could use?
Sidenote
I am using Rails for backend and Ember.js for front end.
If the browser does not support the File API and XMLHttpRequest level 2, there is no other way to upload files in an async/"ajaxy" manner other than reverting to the hidden iframe method. You could, of course, use Flash or Java, but neither of those (especially Java) seem like a good solution to me.
Regardless of the browser, you will have to include a file input element on the page if you want to provide a file chooser for the user. The onchange listener you speak of is vital to determining when the user has actually selected a file or files. In browsers that support the File API, you can also allow users to drop files they wish to upload onto your page. This behavior alone does not require a file input element.
IE9 and older do not support the File API.
I'm quite familiar with this territory as I maintain a fairly popular javascript-only upload library: Fine Uploader.
If this can only be done in some browsers, I'd still like to know how...
Basically, I want to have a drag-and-drop feature where users can drag files to a drop zone and then hit "upload" and have the files uploaded to the server.
I was pondering the possibility of having the option to drag an entire folder to the drop zone and uploading all of the folder contents (preferably skipping any hidden or system folders). I can imagine how this would be done via javascript by simply traversing the folder for files (and sub-folders) and adding those locations to the upload list, but I'm pretty sure that would violate some basic policies (for good reason). But I'm not totally sure, since I know that Firefox 3.6 offers something along these lines.
I am thinking it might be possible if most browser policies make an exception for user-initiated events, but I might be dreaming.
Anybody know for sure?
Browsers (before the file API) did not allow dropping things inside them from outside.
They would get intercepted by the browser and considered as drops to the browser engine..
Perhaps it can/could be done with flash or other embedded technologies.. but not directly through browser and javascript..
http://www.uploadify.com/
This will let you do multiple file upload, but not directory upload. If you use a trusted applet, you can get the functionality you desire. It will require more than pure javascript, though.