Open local html file in current window with Javascript Bookmarklet - javascript

I'm trying to build a sample bookmarklet to grab current webpage source code and pass it to a validator. Validator is not a an online website, but a folder with bunch of javascript and html files. I'm trying to open file:///C:/Users/Electrifyings/Desktop/Validator/Main.html file with the help of javascript bookmarklet code and put the source code in the textarea in the newly opened window, but it is not working for some reasons that I'm not aware of.
Here is the sample code with algorithm:
javascript:(function(){var t = document.body.innerHTML;window.open('file:///C:/Users/RandomHero/Desktop/test.html',_self);document.getElementById("validator_textarea")=t;})()
Here are the steps:
Grab current web page source code in a variable.
Open locally stored HTML web page in current or new window or new tab (either way is fine with me, but no luck)
Put the source code from the variable into the validator textarea of the newly opened HTML file.
I have tried above code with a lot of variations, but got stuck on the part where it opens the new window. Either it's not opening the new window at all or it is opening blank window without loading the file.
Would love to get some help with this issue, thanks a lot.
Oh and btw,
Windows 7 x64, Tried IE, Firefox and Chrome. All latest and stable builds. I guess it's not a browser side issues, but something related to javascript code not opening the URI with file:/// protocol. Let me know if any more details are needed. :)

You wouldn't want a webpage you visit to be able to open up file://c:/Program Files/Quicken/YourSensitiveTaxInfo right? Because then if you make a mistake and go to a "bad" website (either a sleazy one or a good one that's been compromised by hackers), evil people on the intarweb would suddenly have access to your private info. That would suck.
Browser makers know this, and for that reason they put VERY strict limits to prevent Javascript code from accessing files on a user's local computer. This is what is getting in the way of your plan.
Solutions?
build the whole validator in to the bookmarklet (not likely to work unless it's really small)
put your validator code up on the web somewhere
write a plug-in (because the user has to choose to install a plug-in, they get much more freedom than webpages ... even though for Firefox, Chrome, etc. plug-ins are basically just Javascript)
* * Edit * *
Extra bonus solution, if you don't limit yourself to a purely-client-side implementation:
Have your bookmarklet add a normal (HTML) form to the page.
Also add an iframe to the page (it's ok if you hide it with CSS styling)
Set the form's target attribute to point to the iframe. This will make it so that, when the user submits the form and the server replies back to that submission, the server's reply will go to the (hidden) iframe, instead of replacing the page as it normally would.
Add a file input to your form - you won't be able to access the file within that input using Javascript, but that's ok because your server will be doing the accessing, not your bookmarklet.
Write a server-side script which takes the form submissions, reads the file that came with it, and then parrots that file back as the response. In other words, you'll have a URL that you can POST to, and when it sees a file in the POST's contents, it will respond back with the contents of that file.
Now that you've got all that the user can pick their validator file using the file input, upload it to your server, your server will respond back with the file it just got, and that file will appear as the contents of the iframe.
And now that you finally have the file that you worked so hard to get (inside your iframe) you can do $('#thatIframe').html() and viola, you have access to your file. You can save the current page's source and then replace the whole page with that uploaded file (and then pass the saved page source back to the new validator page), or you can do whatever else you want with the contents of the uploaded validator file.
Of course, if the file doesn't vary from computer to computer, you can make all of that much simpler by just having a server that sends the validator file back; this could be a pure Apache server with no logic whatsoever, as all it would have to do is serve a static file.
Either way though, if you go with this approach and your new file upload script is not on the same server as your starting webpage, you will have a new security problem: cross-domain script limitations. However, these limitations are much less strict than local file access ones, so there are ways to work around them (JSONP, cross-site policy files, etc.). There are already tons of great Stack Overflow posts explaining these techniques, so I won't bother repeating them here.
Hope that helps.

Related

How is that jQuery-File-Upload plugin works without Flash or Silverlight?

The jQuery-File-Upload claims to work with IE6+ and there are no open issues about it at https://github.com/blueimp/jQuery-File-Upload
So I am wondering how it accomplishes this when other polyfils to the file API have needed add-ons to access the file system.
As far as I can tell without looking deeply into the code, it will use a iframe.
Look here:
https://github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.iframe-transport.js#L70
The thing is that if you can't do it without ajax/websockets or whatever... then the only possible way to achieve this is to do the request into an iframe.
Inside the iframe, there will be a form with a file input. It will do a request to the server as usual and when the iframe reloads, the javascript code should be able to update the user with the file being uploaded. The iframe could contain something like an id to the file attachement to add to the main form... then on the server it should be possible to link the file attachement to the form.
That's pretty much like that. This method has some disadvantages though because it works within an iframe. Iframes are getting much more restricted for security reasons than they were before.

How to test if an employee is connected via VPN with client-side JavaScript

There are employees that will visit the external site to see a link to an internally hosted site. We only want the link to show if they have VPN'd into the network.
How, with JavaScript, can I test the availability of something that isn't online externally.
I have attempted to use a .JS file but it can get cached and seem available when it really isn't. Same with an image.
Maybe JSONP with MockJax to avoid cross-site scripting errors?
On the intranet site make a JS file that will either embed the links or change them from display: none to display: block (or whatever display). On the page itself simply create a reference to that script and append the current date time to the end to avoid caching from the server.
Test case (this assumes you have localhost set up, but you can change it to be whatever intranet location):
Go here and the text won't be displayed.
Set up a file called test.js under localhost with the contents
$(function(){
$('#test').show();
});
refresh the page and it will display the DIV's contents.

Block JS from loading on certain domains

I have a web service that works through giving users javascript to embed in their code. Users can also place that code on other sites to make it work there. However I also need to allow users to create a blacklist of sites that the JS should not function on. For example, a competitor or an inappropriate site.
Is there a way to check where our JS files are being loaded from, and block loading or break functionality on a per account basis?
Edit: The javascript loads an iframe on the site, so another solution would be to somehow block certain domains from loading an iframe from our server, or serve different content to that iframe
Edit 2: We're also trying to avoid doing this from with the JS because it could be downloaded and modified to get pass the block
Inspecting the url of the page
Yes, the javascript file, when it starts executing, can inspect window.url and see if the url of the main document is ok.
To see where the script was loaded from
It can also go through the dom, looking for the script node which brought in the javascript file itself and see from where the JS was loaded.
However
Anyone can load the javascript into a text editor, then change it to eliminate the tests, then host the modified JS on their own server. Obfuscating or minimizing the JS can slow someone down but obscurity is not security.
One thing you could do is have the javascript load another javascript file. That you serve from the server at a given url. The trick here is that that url will not go to a file but to a server end point that will return a javascript file. The you have that endpoint check for the routes for that user and decide if it will return the javascript you want to work or an error javascript of some kind.
This blog shows how to do it in php.dynamic-javascript-with-php

HTML5 / JavaScript: open text file, load into textarea / save textarea content to text file

I want to do two things in my browser:
Load a text file into a textarea (has to be choosen via dialog box)
Save the content of a textarea into a text file (has to be choosen via dialog box again)
Load a video file and grab the file path to use it with a video player (1)
I've been looking around for a while on the internet. There are some solutions for IE only via ActiveXObjects, which I can't use (IE, seriously?). HTML5 file API has limited usability because I can't access the selected file's path.
I also found save dialogs for textareas, but they ignored line breaks for some strange reason and I don't know how to fix that, if possible at all.
So here are my requirements and options:
Support for FF and Chrome
JavaScript, HTML5 (and PHP, if it has to be)
possibly Silverlight, but I'm not very familiar with it and may only copy and paste :-/
it has to work on Mac as well
There is a dirty hack that gets the job done without resorting to Flash or Silverlight, or using a server, and it works in most browsers:
var uriContent = "data:application/octet-stream," + encodeURIComponent(fileContentsAsString);
window.open(uriContent, 'Save Your File');
JS runs in a sandbox. That means: no access to files on the filesystem. HTML5 file API is the first „native” (as in not flash nor activex) attempt to grant limited access to the users file system.
The File API is HTML that would allow you to access data, after which you can manipulate binary blobs in JavaScript, but as written this is not possible in pure JS and HTML based on your requirements.
The big blocker is "saving to a text file." The only way I've been able to do this is by opening up an iFrame that calls a server side language (such as PHP) to set the content type in the header to a type that prompts a download.
Flash and Silverlight are "client" technologies that run outside of the sandbox, which sounds like your only option at this point.
My ideas:
Load a text file: Use a normal HTML upload form (if you want to script, maybe submit it via AJAX)
Save a text file: Use a textarea and upon submitting, create the file server-side and then offer it to download. (As mentioned before, client-side scripts do not have access to the computer's file system)
Load a video file: Is the video on the server already? Otherwise will need an upload just like the text file. Then use a flash plugin to play the file from the server (the URI should be known to you then)
All of these are relatively simple to achieve using PHP. Line breaks from a textarea stay as \n in PHP.
Tutorials: Form handling in PHP, File upload in PHP
Edit: Since PHP runs server-side you should not run into a lot of problems because of browser diversity. Alternatively, you can do all of these in Flash or Silverlight as well, although from my point of view that takes more learning and is less comfortable for the user.

How can I test JavaScript without placing it on the website?

I'm talking about something like GreaseMonkey but that would accept the script just as it would be on the website. Adding external scripts to Greasemonkey has been a pain for me so far.
So, I have a client who wanted me to write a specific script for him. Because the script reads the URL of the page visited by a user I can only test it on the website but i don't have access to the source code of the website. I'd like to make sure I deliver to the client a 100% working script so I would love to test it first.
How can I do that? Any plugins that would just allow me to copy the script and would run it every time I load a page of the website?
Obviously, if you can, you want to set up a copy of the page on which the script operates, on a local web server where you can play around with things.
If that isn't possible for whatever reason, you can inject your script directly into their site when you're looking at it with your browser using a bookmarklet. The code to do it is roughly:
var script = document.createElement('script');
script.src = "...the path to your script file, ideally on a local web server rather than a file:// path...";
document.body.appendChild(script);
Once you've tweaked the above (pretty much just supplying the src value), you can turn it into a bookmark via the Crunchinator. Once you have your bookmarket, just visit the site you're developing this for and click your bookmarklet, and your script will be added to the page (just for you, obviously, and just for that visit to the page).
Then your develop/test cycle becomes:
Modify the script file (for instance, to fix a bug)
Open their site
Click your bookmarklet to add your script file to the page
Using something like GreaseMonkey can lead to unexpected results since GM runs outside of the Browsers Sandbox and GM scripts always run after everything else has loaded.
My solution for this would probably be:
Setup a local WebServer
Use "Save page..." to get the page contents, then put them on your localhost
Now add your script to the page etc. and make it work
That gives you A) A flexible development environment and B) more "realworld" results, hell you can even edit you hosts file to use the same URL that your client's page has (of course you need to re-edit the file if you want to visit the original page) and C) you can test in IE etc. too.

Categories

Resources