I'm trying to automate some online work through JavaScript and the Firefox (or Chrome) dev console. The work is mostly inputting the same (or similar) data on the same exact pages for many many people.
Example:
unique id
date 1 and 2
some more numbers
I wrote a very simple script that runs in the console and enters the data just fine.
The Problem
My script stops execution whenever it requires the page to reload or it loads another page. I cannot find any information on how to continue executing a script after a page has loaded.
My Limitations
I'm basically limited to what's on FireFox, Chrome, or Edge. Unfortunately, I cannot download any programs or tools that would make the automation any easier right now. Otherwise, I would just use Selenium and Python.
What I've Tried
First I tried to use the script that I describe above (simple DOM manipulation)
Then I tried to use the Selenium browser add-on, but I had to enter a starting URL for it to run. Selenium was not able to get past the login page of our system which is the only static URL that I can use as a starting point.
I then tried to use the Firefox Browser Console (different from the dev console) because the documentation seemed to suggest that I can use JavaScript on the entire browser (not just one tab). Unfortunately, I cannot find any helpful information on how to use the browser console for DOM manipulation. Everything that I search for points to how you create a browser extension, add-on, or how to use JavaScript on your own website.
What I Want To Do
I want to create a script that runs in a dev console. The script should take all of the data either from a separate page or an array then enter the data on each page for each person. I'll also have it prompt the user to verify the data before submission.
What I'm Looking For
What I'm hoping to get from this question is at least one three things.
An answer to the question's title.
Being directed to documentation or some other solution that can solve any of the above problems.
Being told if this is impossible and why by those who have more experience than me (I don't understand if the problem is just a lack of knowledge or limitations on the tools themselves.)
I think you can create a chrome extension and put your code in the background service worker. or use workers read this link
First some backstory:
We have a website that includes a Google Map in the usual way:
<script src="https://maps.googleapis.com/maps/api/js?v=....></script>
Then there is some of our javascript code that initializes the map. Now suddenly yesterday pages started to load but then freezed up entirely. In Chrome this resulted in having to force quit and restart. Firefox was smarter and allowed the user to stop script execution.
Now after some debugging, I found out that a previous developer had included the experimental version of the Google Maps API:
https://maps.googleapis.com/maps/api/js?v=3.exp
So it's likely that something has changed on Google's servers (which is completely understandable). This has uncovered a bug on our end, and both in combination caused the script to hang and freeze up the website and the browser.
Now ok, bug is found and fixed, no big harm done.
And now the actual question:
Is it possible to somehow sandbox these external script references so that they cannot crash my main site. I am loading a decent amount of external javascript files (tracking, analytics, maps, social) from their own servers.
However such code could change at all times and could have bugs that freeze my site. How can I protect my site? Is there a way to maybe define maximum allowable execution time?
I'm open to all kinds of suggestions.
It actually doesn't matter where the scripts are coming from - whether an external source or your own server. Either way they are run in the clients browser. And that makes it quite difficult to achieve your desired sandbox behavior.
You can get a sandbox inside your DOM with the usage of iframes and the keyword "sandbox". This way the content of this iframe is independent from the DOM of your actual website and you can include scripts independent as well. But this is beneficial mainly for security. I am not sure how it would result regarding the overall stability when one script has a bug like an endless loop or similar. But imho this is worth a try.
For further explanation see: https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
I try to debug my JavaScript but the issue is more about VS2012. When I run the website debugger it creates some dynamic pieces of code which you can study while debugging but all the JavaScript code doesn't update once I run the debugger. In short it runs the same JavaScript code as the first time I saved the respective document containing the current code. It seems to me like a pretty huge bug, and therefore it also encouraged me to investigate it through the internet but I seem to be the only one to experience it.
I think that's because you're trying to change the dynamic scripts. It doesn't work...
Instead of that, you should edit your source files and save them. If you do so, you don't need to stop the debugging process and start it again.
Just do edits in the source files and save them, then refresh your running page in browser and it works...
I am trying to reverse-engineer a website I don't own, figuring out how some dumb "encryption" works, in order to be able to carry out some operations automatically, by taking the functionality outside the browser.
One of the files is of particular interest, let's call it javascript.js. It is linked in the HTML document like this
<script src="/javascript.js" type="text/javascript"></script>
I have
deobfuscated javascript.js
pretty-printed its code
My question is now, considering that I'm using venkman and firefox, how to replace the on-site obfuscated javascript.js with my own pretty-printed code, in order to learn how it works.
Any other tool beside venkman should do, as long as I can still step through the deobfuscated code.
Additional question (just in case I may come cross this related situation):
How to do the same if the javascript.js would be emdedded inline in the html code like <script>code</script>?
For those of you wondering about how legal this is, my question is not the first about reverse-engineering on SO: https://stackoverflow.com/questions/tagged/reverse-engineering
Apparently there's no problem with those questions, why should there be one with mine?
My objective is to understand the code AND my question is about the TOOLS, as in "where to point and click" or which tool could help me (if venkman cannot).
You could also always use an intercepting proxy (something like Paros) which will allow you to replace any part of the response any way you like. So when the browser requests the JS file, you can catch the response in Paros, replace the content with your version, and you're done. I often use Paros for other things where I need that interception or observation point, and it's pretty simple and quite numerous in its possible applications. It's basically just a matter of running it and setting your browser proxy settings to use a proxy at localhost on the port Paros is listening on. You can then tell Paros to actually stop and allow you to edit the request or response just by checking a couple of boxes. Hope that helps.
This is going to be very difficult, if not impossible, to do without using browser debugging / extension features like GreaseMonkey or Chrome's Extension API. The reason being that if you don't get involved in the page load sequence, the obfuscated code will already have been run, setting up JavaScript objects, event handlers, etc., etc. You'd have to ensure that your new script replaced those objects and event handlers, which would be complicated and difficult.
With GreaseMonkey or Chrome Extensions or similar on whatever browser you're using, I'd expect it to be possible to detect the page loading script X and replace it with your local script Y. These things run at that level, they get involved in the process.
But despite your goals being aboveboard, debugging on someone else's site is a bad idea. If you introduce a bug through the deobfuscation process, or in the process of trying to understand the code, well that may at least waste time at the other end. I wouldn't be happy with people trying to do it on a site I was running. (That said, a site should be able to handle anything a client throws at it, because you can't trust anything coming from the client side.)
Instead of debugging on their site, I'd probably do my best to record (via Firebug or Chrome/Safari's Dev Tools, etc.) a sample ajax interaction, and then set up a dummy page on my own local server that would simply echo that interaction, playback style. Then you can experiment to your heart's content without risking throwing weird stuff at the site in question. I'd consider it unethical for me to play around in that way with someone else's site, whether they should be able to handle it or not.
Way 1:
Export the web page that uses the code to your drive (I know for sure Opera, Firefox and Chrome supports this - ctrl+s - make sure to save all content). They download all linked content (css, scripts, images), and fix the url's so the downloaded ones are loaded instead. Then replace the javascript file you want to debug and open the downloaded html in a browser, say firefox with firebug, and start debugging. This should work unless the page is heavily ajaxified.
Way 2:
I've managed to get this working in Google Chrome (v8.0.552.215 - I need to update BTW) on a page that has no jQuery (for example w3c.org) - try it yourself, just copy paste it in the address bar and wait for the page to disappear :)
javascript:(eval("var script=document.createElement('script');script.src='http://code.jquery.com/jquery-1.4.4.min.js'; document.getElementsByTagName('head')[0].appendChild(script);window.setTimeout(\"$('body').fadeOut(5000);\", 2000)"));
The script shows up in the scripts section of the console (CTRL+SHIFT+J) and you can set breakpoints. So something like this should work (feel free to modify):
javascript:(eval("for (var allsuspects=document.getElementsByTagName('script'), i=allsuspects.length, oldfile=prompt('Remove script src:'); oldfile && i>=0; i--) if (allsuspects[i] && allsuspects[i].getAttribute('src')!=null && allsuspects[i].getAttribute('src').indexOf(oldfile)!=-1) allsuspects[i].parentNode.removeChild(allsuspects[i]);var script=document.createElement('script');script.src = prompt('Inject script src:');document.getElementsByTagName('head')[0].appendChild(script);"));
The script expanded and explained:
for (var allsuspects=document.getElementsByTagName('script'), i=allsuspects.length, oldfile=prompt('Remove script src:'); oldfile && i>=0; i--)
if (allsuspects[i] && allsuspects[i].getAttribute('src')!=null && allsuspects[i].getAttribute('src').indexOf(oldfile)!=-1)
allsuspects[i].parentNode.removeChild(allsuspects[i]); // remove old script
var script=document.createElement('script'); // inject new script
script.src = prompt('Inject script src:');
document.getElementsByTagName('head')[0].appendChild(script);
The script works only in Chrome (maybe in Safari too?). I've tried Firefox, IE and Opera, but none of them worked. I would guess that there might also be an issue if the file is not available online (if you use you use the 'file://').
UPDATE: also works in Chrome v8.0.552.224
I am working on a solution that loads SharePoint pages in a copy of IE. When the page finishes loading an event is triggered that executes some code in the application that wraps IE.
Now this all works fine and well, until JavaScript is turned off in the browser, a requirement for this solution (Don't ask). Naturally I don't expect the out of the box SharePoint user interface to be fully functional without JavaScript enabled, but although the web page is rendered correctly IE's progress bar never finishes the loading process. As a result my code is never triggered.
Try it for yourself.
Open Internet Explorer.
Disable JavaScript access for the Internet zone.
Navigate to a public SharePoint site such as this one.
Watch in amazement how the progress bar never finishes.
Does anyone have any idea about what is going on or if there are any workarounds?
Answering my own question.
After extensive testing there doesn't appear to be a solution to this problem.
I think the issue that you are having is related to the specific SharePoint site. They are more than likely loading something else in the background that is not part of the base install of SharePoint.
We have some internal sites running on SharePoint and I am able to get the progress bar to completely load with JavaScript disabled on all of them and they are standard installs.
I don't really have an answer as to what the other site might be loading to cause this, but my guess is that it is something that is not necessarily related to SharePoint.