I am stuck at a point where I am getting an image from the server as a binary data and i need to save this image on my PC without any user interference.
Think about it for a moment. If JavaScript could save files to your PC without your explicit consent, every hacker in the world would have access to your PC in a fraction of a second. Flash has enough security problems, JavaScript doesn't need them.
In other words, what you're asking for is impossible for good reason
Maybe the HTML5 File API is something for you. But without user action it would be a huge security hole!
http://updates.html5rocks.com/2011/08/Saving-generated-files-on-the-client-side
http://www.w3.org/TR/file-writer-api/#the-filesaver-interface
Why would you want to save something without user consent? That's never a good idea.
Anyways, JavaScript isn't able to mess with your computer's filesystem, thus it can't save the image to your hard drive. You could use JavaScript to create an image on your web page, using img or canvas, and then ask the user to save it, but exactly what you want is not possible with JavaScript.
On your server page, you could create the binary data, and set certain headers to treat the page as downloadable content, and that's about as close as you can get. It'd still ask for user consent, though.
Related
I have created a webpage but my friends or collegues always copy the source code and copy all the data easily, so is there any way to hide page source option from browser ?
As a rule, if you are putting information on another user's computer (whether because you made a document or they viewed your webpage), you really can't control what they do with it.
This is an issue that larger companies deal with often. Have you heard of DRM? It's a mechanism that companies like to try to use to control how people can connect to their services, use their content and in general, try to exert control over their data while it's on your system.
Now, a web page is a relatively simple container for holding information. You expressed an urge to prevent your friends from copying the source code. You could try to encrypt it, but if it's using local data to decrypt itself, there still isn't going to be anything that stops them from just copying what's in the View Source window and running it again (even if they can't really read it).
I'd suggest that you don't worry about it. If what you have on your page is so important that others shouldn't be able to see it, don't put it on a webpage.
Finally, Google doesn't much care that you're able to view the source to their home page. Why not? Because the value of the search engine isn't in what the home page looks like, but in the data on the back-end that you don't have direct access to. The value is in the algorithms that execute on the server when you hit that Google Search button that queries that data and returns the information you're looking for. There's very little relative value in the generated HTML that you see in the page. Take a leaf from their book and don't stress that they copy your HTML.
No , there isnt any way to do it, however you can disable right clicking in browser via javascript, but still they can use shortkeys to open developer view (in chrome F12) and see the source. You cannot hide html or javascript from client, but maybe you can make it harder to read.
No. Your HTML output is in the user's realm. Even if there was a way to disable view source in one client, a user could use a different one
Always assume that your site's HTML is fully available to end users.
Yes and no. You can definitely make HTML and JS harder to intrepret by obfuscating your code - that is, taking your code and making it look confusing. Here is a tool that can do that: http://www.colddata.com/developers/online_tools/obfuscator.shtml
However, these things all use code, and code can be decrypted through any number of methods. If you post a song to the internet, even if they cannot find the mp3, they can simply record their speakers. If you upload an image and prevent users from downloading it, they can take a screenshot or use their camera. In order for HTML and Javascript to work, it has to be intrepreted by their computer, and even if you do find a way to disable "View Source" there are others ways, like a DOM inspector (F12 in IE/Chrome, Ctrl+Shift+K in Firefox).
As a workaround, use copyright, warn your users they will be punished if they copy your code, and put watermarks, labels and logos over any mp3s or images you don't want stolen. In the end, disabling right clicking (which is also possible, see How do I disable right click on my web page? ) or disabling selection (also possible) does nothing, because there is more than one way to get your code, like searching through temporary internet files.
However, you ask "what if I want a site where my users can log in and I need security? How can I make it so nobody can see my code then? Doesn't it have to be secure and not out in the open?"
And the answer is, yes, it needs to be secure. That's what server-side languages, like PHP, are for. PHP does all the work on the server itself so the user cannot see it. PHP is like a pre-rendered language - rather than doing it in real-time, PHP does all the work beforehand so the user's computer doesn't have to, making the code safe. The code is never put onto the user's computer, because the user's computer doesn't need it. The work is done by the website itself before the page is sent. SSL is often paired with PHP to make absolutely sure that websites have not been hacked.
But HTML and Javascript have to be done in real time on the user's computer, so you cannot disable View Source because it is useless. There are many, many ways that users could get around it, even if View Source is disabled, and even if right clicking is disabled.
If your code doesn't need to be secure, however, I'd recommend you consider keeping it open source. :)
I recently started building a bookmarklet that displays the EXIF data of any image on a website. I chose to use Nihilogic's binary.js and exif.js libraries. For images hosted on the same domain as the parent page, the script works wonderfully. But because it uses XHR to read the binary data of images, and because XHR is restricted to same-origin requests, I can't access the binary data of any cross-site-hosted images.
Is there a way to load the binary data of an image locally (or at least without using XHR) that preserves EXIF data?
I've explored a few other directions, but I fear I don't understand them well enough to determine if there's a solution:
JSONP - I'm assuming there's no way to get binary data into one of these things.
canvas tags - these seem to produce very different base64 encodings than what PHP does, and I suspect that the EXIF data no longer exists in the new encoding.
Javascript is allowed to do special operations (like on the canvas) with same-origin images and cors-enabled images because the browser can safely assume that those would be OK to upload to the server in the first place. But then it gets complicated...
I can't access the binary data of any cross-site-hosted images.
Yes, generally it is very important that you can't. More to the point, you can't do what you want with a bookmarklet.
You can't do this with a canvas because the cors rules here are strict (for good reasons!)
In short the reasoning in general is pretty much exactly the same. Browsers are in a unique security position: A random page on the internet can show you things that are private to you, such as the hypothetical image, C:\MyPhotos\privateImage1.jpg, assuming it could guess that file path.
But that webpage is most certainly not allowed to do anything with that file other than show it to you. It can't read the binary information (EXIF information or pixel information). JavaScript is not allowed to know what that image looks like or nearly any data associated with it.
If it was able to figure that out, a random webpage would be able to try a bunch of file paths and maybe come across an image on your hard drive, and then upload the binary data of that image to a server, in effect stealing your private image.
A browser extension would be far more suited to this task than a (JavaScript) bookmarklet because of this.
Purely from the client? I doubt it. How about XHR'ing a local PHP script that runs something like exif_imagetype()? This function works on remote as well as images.
Our webform has a file upload, and just a regular picture box on it. Now we already have the code to save the pictures and retrieve them, but how would you display the picture they selected without first saving it, then refreshing the page and displaying it? Is this a javascript thing?
Thanks in advance.
Most browsers do not allow this. Filed picked will be submitted with the form, but will not be available to javascript. This is to prevent javascript from having access to local files.
Your best solution is to use AJAX to upload the file, then retrieve it from the server and display it. This solution makes it so the initial view takes longer, but if the user then decides it is the file they want, you can avoid sending it to the server again and just move it from a temporary storage area to a permanent one.
This definitely is not possible with JavaScript. It might be possible with a Flash uploader (but I really don't know Flash). JavaScript does not have any sort of direct access to the host's file system.
On second thought - it might be possible to inject an img tag whose src is a file:// URL. I'm not sure about this, though. Checking now.
I have a Firefox component for PDF signing that I invoke via Javascript. The problem is that this component outputs the signed PDF as a file on the user's filesystem - there is no way to get a byte[], stream or similar.
I need to post this signed PDF file back to the server. Is it possible to do this in plain Javascript, without additional Firefox components?
You can't do this without under intervention, this would he a huge security hole. Think about visiting a webpage and it being able to grab and upload any of your files without you doing a thing...you can see how this would be abused really fast.
You might be able to do this with a Firefox extension, I'm not sure of the security limitations it imposes (though I wouldn't be surprised if it disallowed this as well), but JavaScript would not be an option here.
There's no direct way to access data on a user's file system within a browser unless you're doing it through an extension. This would be a huge security risk.
If the file can be put into an <input type="file" /> element in Firefox, you can use JavaScript to automatically upload the data to the server without user intervention, but you would need something to initially get the file into the page's memory, not the file system.
Hell no - And for very good reason. You wouldn't want every Tom, Dick and Harry automatically grabbing all your files.
I believe it's the file input that needs user interaction. You can post the form automatically but you can't fill it in.
IMO your best bet is replacing the whole Firefox component with a single Java applet - I'd all but guarantee there's a Java project for PDF signing. Perhaps even Flash or Silverlight as long as you can do what you need with your PDF.
I need a Javascript sample which reads contents from a url and creates a file in the client with same contents when some button is clicked. I also understand that Javascript cannot be allowed to access the local file system (Unless you use ActiveX objects). I do not want to rely on ActiveX objects (since my client is not IE always).
So here is what I did. I used the standard XmlHttpRequest made a request and got my bytes. Now I thought I could kinda stream this contents to the user, first by opening a standard dialog box (the box that pops up when you attempt download something from internet with options like Open/Save/Cancel) and then asking the user to save it somewhere.
I know how to do the read part, can someone show some javascript/html sample on "How to stream open a confirm dialog box to the user and stream some contents?"
PS: Not too sure if this could be done in javascript at all but with Javascript you never know what is possible and what is not :)
Rather than using Javascript to stream the content, which is not possible for obvious security reasons, you need to point the browser at a URL that will return a 'Content-Type' header of 'application/octet-stream'. In most cases this will force the browser to initiate a 'save as' operation and ask the user what to do with it.
I believe it is possible to do this using an iframe in the same page, such that the user will not have to navigate away from the page or open a new tab/window.
See it this way: if you could read/write to users' computers using JavaScript, then no computer would be safe from browsing the web.
Having said so, you cannot read/write client-side files using JavaScript.
But you could if you use Flash / a Java applet; in those cases the embedded objects asks for your permission before doing such actions.
You may want to have a look at TiddlyWiki that claims it can write itself to the disk...
If I understand what your question is, then you want to use JavaScript to write data like a server-side script would (PHP, Python, Java, etc..) but in browser?
If so, then what your asking isn't possible with in browser JavaScript.
However if for some reason you wanted to do this with server-side JavaScript, then yes the "streaming" part is possible.