If this were possible to do prior to posting a form, it may save me having to upload the file to my server...
To do that you would have to load the file's binary information into JavaScript. Which is not possible.
But here's an implementation of SHA1 in JavaScript.
Actually you can read the contents of a client-side file now, as long as it's chosen in a file upload field and you are using Firefox. See the input.files array. You can then indeed hash it, although it might be rather slow.
See How would I get a Hash value of a users file with Javascript or Flash? for an example and a compact SHA-1 implementation.
It is possible to use SHA1, though performance isn't going to be the best...
For anything over a few hundred KB's you will have to run some benchmarks and determine if indeed its a viable solution.
See this link for a good implementation (passpack and quite a few OS projects use it)
Edit:
As other have already replied, actually getting the file contents may be a whole different matter - so unless you use something like Google Gears or Adobe AIR it should be virtually impossible.
One can read their local file using the HTML5 File interface: https://developer.mozilla.org/en-US/docs/Web/API/File
And then you can use a library for like Crypto.js https://code.google.com/p/crypto-js/ to finish the hash over the read text.
No, you can't access a file from a local computer using JavaScript .
You're going to have to upload it first to the server, then checking the checksum of the file.
Not natively, no, and this is a bad idea anyway. Every byte in the file will have to be loaded into memory by Javascript, and you'd need a way to get it there.
If you must do this and you've got a way to put the file's binary information into your script, then there's plenty of third-party scripts you can use. Here's one, for example.
You could do this with a Java applet. I've never used any of them, but there are quite a few Java upload applets out there. The hash algorithm itself is available with Java and can be accessed through java.security.MessageDigest. If the client doesn't have the Java plug-in available you could just fail back to a regular upload and hash on the server.
A side note: depending upon why you're hashing the file you'll probably want to re-hash it on the server after the upload rather than trust the client.
Related
Is there any way to hide the CSS and JavaScript file from the client-side user and still embed it in the webpage shown to the user?
No. CSS and Javascript must be parsable and readable by the browser, therefore a human can get access to the same data.
It is possible to obscure/compress/minify the javascript, but all that generally does is remove whitespace and rename/shorten variable names. The script is still functional and anyone interesting in how it really works can still figure it out (perhaps by using some tools to reformat it) with a little more time.
The typical reasons for minification is to reduce the download size of your scripts (speeding up site performance), but it also has the side effect of making the code harder to read by a human. One should not count on minification providing any real protection as the code can be reformatted and still understood by anyone determined to do so.
If you need to keep something private, keep the logic on the server and don't put it in the client. Clients can access server-based functionality via ajax if need be.
I've never heard of anyone thinking there was a business reason to protect CSS. It's layout/presentation formatting.
You can always minify the JavaScript file to make it harder for someone to reads it or to modify it.
For example : http://www.minifyjavascript.com/
You can also do the same thing with CSS.
http://developer.yahoo.com/yui/compressor/
(it can do both JavaScript and CSS)
There are other sites that offers a way to minify the files, but there is no way to hide it completely from the client-side.
Minification and base64 encoding. Here's SO questions about base64 encoding. Be mindful that all you're doing is making the process of looking at your code miserable and no more.
Online encoder/decoder.
Is it possible to not allow people view one of my website's JS file?
Demo:
http://js.maxmind.com/js/geoip.js
If you copy the URl and paste it in the browser, it will say "Unauthorized". But if you put it inside the HTML, it will do it's work.
Can I do that with my code.js file?
JavaScript is an interpreted computer programming language. It's not being compiled and it runs on the client's browser/computer, therefore, the client must see the script in order to execute it. That's why you cannot hide the code.
You can define in your server folders as restricted and that means the user can not access them directly, but when the browser loads the page it have to load all the components such as images, css files, js files etc...
If the browser can load them, it means the user can see them as well.
For example, you can also define that users are not authorized to see any .jpg files but they can easily save any image. Actually the browsers usually saves the images anyway on your local computer and cache them, so next time you load the page, it won't have to download files that weren't changed again.
As others already mentioned, trying to hide a js code is very bad practice and you need to avoid it. If you want the make the life hard for other developers that wants to copy your code you can use this site to obfuscate your js code, but remmeber, it only makes it harder to read by humans, it does not provide you any security.
First, let me explain loud and clear: that is the worst security I can imagine for what it is trying to do. It is just shouting, "HEY NOBODY LOOK AT THIS INSECURE FILE."
Your question has been viewed 41 times so far. That means up to 41 people are wondering what that mysterious does and probably half of them can find easily out. In short, don't do this.
There is no client side security. I refer you to this answer, for instance.
As for how to implement the situation, as noted in comment it's probably done by checking the referrer header. To find out fully check the request headers in the dev tools in your browser and compare to the request headers used by curl (e.g. by using a post bin).
It is not possible to not allow people to view one of your website's JS files.
To be more precise, if someone can execute your JS file, they can view it.
Although you cannot prevent a user from being able to look at your javascript you can make it extremely difficult for them to understand what they are looking at through obfuscation or minification, for the latter there are many services that will do this for you; look at this for example. As for obfuscation I don't know of any way to do it automatically but it would be a similar approach.
If you have information in the javascript that you truly cannot allow a user to see, then I would suggest moving it into the server side code and only pass to the javascript the absolute minimum. As I am not sure what you are using on the server side I cannot give you a specific example; however in the past when using MVC I achieved this by passing the values I needed either to a hidden input ( if the value needed to be posted back with a form) or through jQuery.Data
On a webpage, is it possible to split large files into chunks before the file is uploaded to the server? For example, split a 10MB file into 1MB chunks, and upload one chunk at a time while showing a progress bar?
It sounds like JavaScript doesn't have any file manipulation abilities, but what about Flash and Java applets?
This would need to work in IE6+, Firefox and Chrome. Update: forgot to mention that (a) we are using Grails and (b) this needs to run over https.
You can try Plupload. It can be configured to check whatever runtime is available on users side, be it - Flash, Silverlight, HTML5, Gears, etc, and use whichever satisfies required features first. Among other things it supports image resizing (on users side, preserving EXIF data(!)), stream and multipart upload, and chunking. Files can be chunked on users side, and sent to a server-side handler chunk-by-chunk (requires some additional care on server), so that big files can be uploaded to a server having max filesize limit set to a value much lower then their size, for example. And more.
Some runtimes support https I believe, some need testing. Anyway, developers on there are quite responsive these days. So you might at least try ;)
The only option I know of that would allow this would be a signed Java applet.
Unsigned applets and Flash movies have no filesystem access, so they wouldn't be able to read the file data. Flash is able to upload files, but most of that is handled by the built-in Flash implementation and from what I remember the file contents would never be exposed to your code.
There is no JavaScript solution for that selection of browsers. There is the File API but whilst it works in newer Firefox and Chrome versions it's not going to happen in IE (no sign of it in IE9 betas yet either).
In any case, reading the file locally and uploading it via XMLHttpRequest is inefficient because XMLHttpRequest does not have the ability to send pure binary, only Unicode text. You can encode binary into text using base-64 (or, if you are really dedicated, a custom 7-bit encoding of your own) but this will be less efficient than a normal file upload.
You can certainly do uploads with Flash (see SWFUpload et al), or even Java if you must (Jumploader... I wouldn't bother, these days, though, as Flash prevalence is very high and the Java plugin continues to decline). You won't necessarily get the low-level control to split into chunks, but do you really need that? What for?
Another possible approach is to use a standard HTML file upload field, and when submit occurs set an interval call to poll the server with XMLHttpRequest, asking it how far the file upload is coming along. This requires a bit of work on the server end to store the current upload progress in the session or database, so another request can read it. It also means using a form parsing library that gives you progress callback, which most standard language built-in ones like PHP's don't.
Whatever you do, take a ‘progressive enhancement’ approach, allowing browsers with no support to fall back to a plain HTML upload. Browsers do typically have an upload progress bar for HTML file uploads, it just tends to be small and easily missed.
Do you specifically need it two be in X chunks? Or are you trying to solve the problems cause by uploading large files? (e.g. can't restart an upload on the client side, server side crashes when the entire file is uploaded and held in memory all at once)
Search for streaming upload components. It depends on what technologies you are working with as to which component you will prefer jsp, asp.net, etc.
http://krystalware.com/Products/SlickUpload/ This one is a server side product
Here are some more pointers to various uploaders http://weblogs.asp.net/jgalloway/archive/2008/01/08/large-file-uploads-in-asp-net.aspx
some try to manage memory on the server,e.g. so the entire huge file isn´t in memory at one time, some try to manage the client side experience.
Is it possible to read a file in from a path in JavaScript and create a byte[] of that file?
Yes, you can — in Firefox, anyway. Other browsers may or may not choose to allow it in the future.
Make a file upload field for the user to pick the file, and read it through the input.files list. eg. document.getElementById('myuploadfield').files[0].getAsBinary(). This puts each byte in a single character of a JavaScript String, which is about as close to a byte[] as you're going to get.
This is quite a specialized interface and probably Not The Right Thing — heed the other replies, because it's very possible you are trying to do something in a inappropriate way. Difficult to tell without context.
There are two forms of JavaScript: client-side and server-side. In client-side JavaScript it is not possible, while in server-side JavaScript, it is possible. So it depends on whether you are using client-side or server-side JavaScript.
That said, client-side JavaScript is much more common and if you were using server-side JavaScript, you would probably know the answer to your question. So I'm going to go out on a limb and say that no, it is not possible to read in from a path in JavaScript and create a byte[] from that file.
(Also, it's unclear what you mean by a byte[]; that's not a common notation when using JavaScript. Are you sure you aren't talking about Java? Java is completely different from JavaScript: in Java byte[] is a more common notation.)
No. JavaScript is purposely designed to have very minimal file IO (think cookies) because allowing it to access arbitrary files (local and remote) would be a massive security risk.
You guys seem to have completely forgotten mobile platforms and javascript designed to run with no-security flags set what-so-ever. I access my files just fine in my javascript code, which runs on my iPhone. You just cant access the users filesystem, only your own filesystem which is basically a folder isolated from the rest of the system.
Sp his question was perfectly valid.
Also - you should look up Javascript blobs (binary large objects) and typed arrays. You can allocate "normal" byte, word and longword arrays in JS - but people rarely use them.
File I/O in Javascript is considered a serious security risk:
http://forums.devshed.com/javascript-development-115/file-i-o-with-javascript-10376.html
I am a novice-intermediate programmer taking a stab at AJAX. While reading up on JavaScript I found it curious that most of the examples I've been drawing on use PHP for such an operation. I know many of you may argue that 'I'm doing it wrong' or 'JavaScript is a client-side language' etc. but the question stands. . .can you write a file in only JavaScript?
Yes, of course you can. It just depends on what API objects your javascript engine makes available to you.
However, odds are the javascript engine you're thinking about does not provide this capability. Definitely none of the major web browsers will allow it.
You can write cookies with Javascript, on newer browsers you also have an SQLite database to store client side data. You cannot store data in an arbitrary location on the disk though.
You can use something like Google Gears to produce JS applications which are capable of storing data in a local cache or database. You can't read or write arbitrary areas of the disk though. (This was written in 2009 - Google Gears is now deprecated)
These days, you should be looking at the local storage capabilities provided by HTML5
No. You could use JavaScript to create an AJAX request to a server-side processing script, but allowing JS to directly write to disk - either client-side or server-side - would be a massive, nasty, glaring, unforgivable browser security hole.
The short answer is no; you cannot by default write a file to the local disk, by using plain JavaScript in a browser. You'll need a helper to do that. For example, TiddlyWiki is a wiki engine that is just a single, static HTML file, but it can write itself to disk with the help of a Java applet (Tiddly Saver).
You can in Windows Scripting Host.
Next version of chrome (v52) made this possible with fetch api + service worker + streams, you can enable streams now with a flag...
you can go to the StreamSaver.js to see some examples of how to use it.
You can do something like this:
const writeStream = fs.createWriteStream('filename.txt')
const encoder = new TextEncoder
let data = 'a'.repeat(1024)
let uint8array = encoder.encode(data + "\n\n")
writeStream.write(uint8array)
writeStream.close()
Or just go ahead and look at the demos: https://jimmywarting.github.io/StreamSaver.js/example.html
Nope, Javascript is not allowed to access the filesystem at all, its a security restriction in the browser. The only way you can really do it is with ActiveX, but then your limiting yourself to using IE.
Edit:
AS the above post states, it could be possible if your engine allowed it, however I don't know of one browser engine (which is what I asusme you are writing it for) that will allow you to.
If you just need to let user download a file (.txt, .csv, images and others) via browser download dialog, you can use data URIs with <a href=... download=.../> tag.
For example (for text file):
Click to download
You can also set the attribute href and download using javascript, and use element.click() to trigger the download.
However, this method cannot write a file without user confirming the file download dialog.