I need to detect the size of the file before upload.
I need it to work in IE8, thus not HTML5
It needs to be entirely client side.
I need to be able to specify file size limit.
I am aware that ActiveX can be used, but I cannot use that due to it requiring the user to 'permit' it.
I have tested BlueImps plugin, but it doesn't seem to work and the documentation does not seem to state browser support.
Can anyone suggest a plugin/method with fits with my criteria.
If you're willing to introduce a dependency on Flash, then you could use that to get the file size (and handle the upload too).
Flash supports file-selection via the FileReference class, which gives you access to some metadata including the file size.
With some help from the ExternalInterface class, you could call a JavaScript function and give it this information.
You could then upload the file from Flash instead of with the usual input element, if the file size is appropriate.
Check out YUI's uploader for a really easy-to-use and well-documented free component that handles all this for you (you only need to write a little JavaScript, and you can style the pre-built Flash component however you want).
Related
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.
I need to upload certain file sizes using plupload. For example, small, medium and big picture .
Is possible do that with only javascript?
You can insert a function to resize image when it is uploaded.
if (!$chunks || $chunk == $chunks - 1) {
// Strip the temp .part suffix off
rename("{$filePath}.part", $filePath);
resize_image($filePath);
}
No. JavaScript is scripting language only.
It has not libraries to help manipulate things like images, copy files, send emails, etc .. We can invoke server side utilities or injected proxies but it was invented specifically for DOM manipulation
In the question OP was specifically looking at using JavaScript to manipulate the image and use plupload to upload it. This in impossible because JS on its own cannot do that.
The default plugins for plupload rely on either silverlight, flash or gears and respectively those platform can manipulate images locally and then call upload with the resized file- which will upload to the server.
Possibly OP at the time I wanted to avoid flash, silverlight etc to keep cross browser compatibility and for use on old browsers.
So a good solution is to uplaod the file to the server and use .NET/PHP tools to manipulate the images the way it was needed. While retaining the original image. It works well and you can restrict image sizes to 5mb; which can cause some bas user experience but that is a good trade off.
I'm looking a quick way to add an (multi) image unloader with client side crop to an ASP.NET MVC site and for some reason the search seems to be much more complicated than I thought :(
upload image (can be via form post or custom, just has to work with ASP.NET)
custom crop possibility before upload
(preferred) multiple images at once
It doesn't matter if js/jquery, silverlight or flash is used, it just has to work, its an internal application and I can force people to have the necessary plugins installed.
Basically this is exactly what I want:
http://i-load.radactive.com/
But they are out of business and it seems impossible to get a license :(
**UPDATE**
This should be an all in one solution, I currently do not have the time to figure out how to connect multiple components.
I'm willing to purchase a component that does this, but I simply can't find one, which I find rather strange.
An internal application where you are comfortable with ASP.NET then Silverlight would be the good direction to look in.
There is free multiple file uploader which is designed to work with an ASP.NET server end here: http://silverlightuploader.codeplex.com/
There are number of ways to manipulate an image in Silverlight, either natively or with other Silverlight tools such as: http://writeablebitmapex.codeplex.com/
Finally you can re-encode images to common formats such as PNG with: http://imagetools.codeplex.com/
Whether you could actually combine these as is to acheive your goals would be another matter.
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.