So apparently because of the recent scams, the developer tools is exploited by people to post spam and even used to "hack" accounts. Facebook has blocked the developer tools, and I can't even use the console.
How did they do that?? One Stack Overflow post claimed that it is not possible, but Facebook has proven them wrong.
Just go to Facebook and open up the developer tools, type one character into the console, and this warning pops up. No matter what you put in, it will not get executed.
How is this possible?
They even blocked auto-complete in the console:
I'm a security engineer at Facebook and this is my fault. We're testing this for some users to see if it can slow down some attacks where users are tricked into pasting (malicious) JavaScript code into the browser console.
Just to be clear: trying to block hackers client-side is a bad idea in general;
this is to protect against a specific social engineering attack.
If you ended up in the test group and are annoyed by this, sorry.
I tried to make the old opt-out page (now help page) as simple as possible while still being scary enough to stop at least some of the victims.
The actual code is pretty similar to #joeldixon66's link; ours is a little more complicated for no good reason.
Chrome wraps all console code in
with ((console && console._commandLineAPI) || {}) {
<code goes here>
}
... so the site redefines console._commandLineAPI to throw:
Object.defineProperty(console, '_commandLineAPI',
{ get : function() { throw 'Nooo!' } })
This is not quite enough (try it!), but that's the
main trick.
Epilogue: The Chrome team decided that defeating the console from user-side JS was a bug and fixed the issue, rendering this technique invalid. Afterwards, additional protection was added to protect users from self-xss.
I located the Facebook's console buster script using Chrome developer tools. Here is the script with minor changes for readability. I have removed the bits that I could not understand:
Object.defineProperty(window, "console", {
value: console,
writable: false,
configurable: false
});
var i = 0;
function showWarningAndThrow() {
if (!i) {
setTimeout(function () {
console.log("%cWarning message", "font: 2em sans-serif; color: yellow; background-color: red;");
}, 1);
i = 1;
}
throw "Console is disabled";
}
var l, n = {
set: function (o) {
l = o;
},
get: function () {
showWarningAndThrow();
return l;
}
};
Object.defineProperty(console, "_commandLineAPI", n);
Object.defineProperty(console, "__commandLineAPI", n);
With this, the console auto-complete fails silently while statements typed in console will fail to execute (the exception will be logged).
References:
Object.defineProperty
Object.getOwnPropertyDescriptor
Chrome's console.log function (for tips on formatting output)
I couldn't get it to trigger that on any page. A more robust version of this would do it:
window.console.log = function(){
console.error('The developer console is temp...');
window.console.log = function() {
return false;
}
}
console.log('test');
To style the output: Colors in JavaScript console
Edit Thinking #joeldixon66 has the right idea: Disable JavaScript execution from console « ::: KSpace :::
Besides redefining console._commandLineAPI,
there are some other ways to break into InjectedScriptHost on WebKit browsers, to prevent or alter the evaluation of expressions entered into the developer's console.
Edit:
Chrome has fixed this in a past release. - which must have been before February 2015, as I created the gist at that time
So here's another possibility. This time we hook in, a level above, directly into InjectedScript rather than InjectedScriptHost as opposed to the prior version.
Which is kind of nice, as you can directly monkey patch InjectedScript._evaluateAndWrap instead of having to rely on InjectedScriptHost.evaluate as that gives you more fine-grained control over what should happen.
Another pretty interesting thing is, that we can intercept the internal result when an expression is evaluated and return that to the user instead of the normal behavior.
Here is the code, that does exactly that, return the internal result when a user evaluates something in the console.
var is;
Object.defineProperty(Object.prototype,"_lastResult",{
get:function(){
return this._lR;
},
set:function(v){
if (typeof this._commandLineAPIImpl=="object") is=this;
this._lR=v;
}
});
setTimeout(function(){
var ev=is._evaluateAndWrap;
is._evaluateAndWrap=function(){
var res=ev.apply(is,arguments);
console.log();
if (arguments[2]==="completion") {
//This is the path you end up when a user types in the console and autocompletion get's evaluated
//Chrome expects a wrapped result to be returned from evaluateAndWrap.
//You can use `ev` to generate an object yourself.
//In case of the autocompletion chrome exptects an wrapped object with the properties that can be autocompleted. e.g.;
//{iGetAutoCompleted: true}
//You would then go and return that object wrapped, like
//return ev.call (is, '', '({test:true})', 'completion', true, false, true);
//Would make `test` pop up for every autocompletion.
//Note that syntax as well as every Object.prototype property get's added to that list later,
//so you won't be able to exclude things like `while` from the autocompletion list,
//unless you wou'd find a way to rewrite the getCompletions function.
//
return res; //Return the autocompletion result. If you want to break that, return nothing or an empty object
} else {
//This is the path where you end up when a user actually presses enter to evaluate an expression.
//In order to return anything as normal evaluation output, you have to return a wrapped object.
//In this case, we want to return the generated remote object.
//Since this is already a wrapped object it would be converted if we directly return it. Hence,
//`return result` would actually replicate the very normal behaviour as the result is converted.
//to output what's actually in the remote object, we have to stringify it and `evaluateAndWrap` that object again.`
//This is quite interesting;
return ev.call (is, null, '(' + JSON.stringify (res) + ')', "console", true, false, true)
}
};
},0);
It's a bit verbose, but I thought I put some comments into it
So normally, if a user, for example, evaluates [1,2,3,4] you'd expect the following output:
After monkeypatching InjectedScript._evaluateAndWrap evaluating the very same expression, gives the following output:
As you see the little-left arrow, indicating output, is still there, but this time we get an object. Where the result of the expression, the array [1,2,3,4] is represented as an object with all its properties described.
I recommend trying to evaluate this and that expression, including those that generate errors. It's quite interesting.
Additionally, take a look at the is - InjectedScriptHost - object. It provides some methods to play with and get a bit of insight into the internals of the inspector.
Of course, you could intercept all that information and still return the original result to the user.
Just replace the return statement in the else path by a console.log (res) following a return res. Then you'd end up with the following.
End of Edit
This is the prior version which was fixed by Google. Hence not a possible way anymore.
One of it is hooking into Function.prototype.call
Chrome evaluates the entered expression by calling its eval function with InjectedScriptHost as thisArg
var result = evalFunction.call(object, expression);
Given this, you can listen for the thisArg of call being evaluate and get a reference to the first argument (InjectedScriptHost)
if (window.URL) {
var ish, _call = Function.prototype.call;
Function.prototype.call = function () { //Could be wrapped in a setter for _commandLineAPI, to redefine only when the user started typing.
if (arguments.length > 0 && this.name === "evaluate" && arguments [0].constructor.name === "InjectedScriptHost") { //If thisArg is the evaluate function and the arg0 is the ISH
ish = arguments[0];
ish.evaluate = function (e) { //Redefine the evaluation behaviour
throw new Error ('Rejected evaluation of: \n\'' + e.split ('\n').slice(1,-1).join ("\n") + '\'');
};
Function.prototype.call = _call; //Reset the Function.prototype.call
return _call.apply(this, arguments);
}
};
}
You could e.g. throw an error, that the evaluation was rejected.
Here is an example where the entered expression gets passed to a CoffeeScript compiler before passing it to the evaluate function.
Netflix also implements this feature
(function() {
try {
var $_console$$ = console;
Object.defineProperty(window, "console", {
get: function() {
if ($_console$$._commandLineAPI)
throw "Sorry, for security reasons, the script console is deactivated on netflix.com";
return $_console$$
},
set: function($val$$) {
$_console$$ = $val$$
}
})
} catch ($ignore$$) {
}
})();
They just override console._commandLineAPI to throw security error.
This is actually possible since Facebook was able to do it.
Well, not the actual web developer tools but the execution of Javascript in console.
See this: How does Facebook disable the browser's integrated Developer Tools?
This really wont do much though since there are other ways to bypass this type of client-side security.
When you say it is client-side, it happens outside the control of the server, so there is not much you can do about it. If you are asking why Facebook still does this, this is not really for security but to protect normal users that do not know javascript from running code (that they don't know how to read) into the console. This is common for sites that promise auto-liker service or other Facebook functionality bots after you do what they ask you to do, where in most cases, they give you a snip of javascript to run in console.
If you don't have as much users as Facebook, then I don't think there's any need to do what Facebook is doing.
Even if you disable Javascript in console, running javascript via address bar is still possible.
and if the browser disables javascript at address bar, (When you paste code to the address bar in Google Chrome, it deletes the phrase 'javascript:') pasting javascript into one of the links via inspect element is still possible.
Inspect the anchor:
Paste code in href:
Bottom line is server-side validation and security should be first, then do client-side after.
Chrome changed a lot since the times facebook could disable console...
As per March 2017 this doesn't work anymore.
Best you can do is disable some of the console functions, example:
if(!window.console) window.console = {};
var methods = ["log", "debug", "warn", "info", "dir", "dirxml", "trace", "profile"];
for(var i=0;i<methods.length;i++){
console[methods[i]] = function(){};
}
My simple way, but it can help for further variations on this subject.
List all methods and alter them to useless.
Object.getOwnPropertyNames(console).filter(function(property) {
return typeof console[property] == 'function';
}).forEach(function (verb) {
console[verb] =function(){return 'Sorry, for security reasons...';};
});
However, a better approach is to disable the developer tool from being opened in any meaningful way
(function() {
'use strict';
Object.getOwnPropertyNames(console).filter(function(property) {
return typeof console[property] == 'function';
}).forEach(function (verb) {
console[verb] =function(){return 'Sorry, for security reasons...';};
});
window.addEventListener('devtools-opened', ()=>{
// do some extra code if needed or ...
// maybe even delete the page, I still like to add redirect just in case
window.location.href+="#";
window.document.head.innerHTML="";
window.document.body.innerHTML="devtools, page is now cleared";
});
window.addEventListener('devtools-closed', ()=>{
// do some extra code if needed
});
let verifyConsole = () => {
var before = new Date().getTime();
debugger;
var after = new Date().getTime();
if (after - before > 100) { // user had to resume the script manually via opened dev tools
window.dispatchEvent(new Event('devtools-opened'));
}else{
window.dispatchEvent(new Event('devtools-closed'));
}
setTimeout(verifyConsole, 100);
}
verifyConsole();
})();
Internally devtools injects an IIFE named getCompletions into the page, called when a key is pressed inside the Devtools console.
Looking at the source of that function, it uses a few global functions which can be overwritten.
By using the Error constructor it's possible to get the call stack, which will include getCompletions when called by Devtools.
Example:
const disableDevtools = callback => {
const original = Object.getPrototypeOf;
Object.getPrototypeOf = (...args) => {
if (Error().stack.includes("getCompletions")) callback();
return original(...args);
};
};
disableDevtools(() => {
console.error("devtools has been disabled");
while (1);
});
an simple solution!
setInterval(()=>console.clear(),1500);
I have a simple way here:
window.console = function () {}
I would go along the way of:
Object.defineProperty(window, 'console', {
get: function() {
},
set: function() {
}
});
In Firefox it dosen't do that, since Firefox is a developer browser, I think since the command WEBGL_debug_renderer_info is deprecated in Firefox and will be removed. Please use RENDERER and the error Referrer Policy: Less restricted policies, including ‘no-referrer-when-downgrade’, ‘origin-when-cross-origin’ and ‘unsafe-url’, will be ignored soon for the cross-site request: https://static.xx.fbcdn.net/rsrc.php/v3/yS/r/XDDAHSZfaR6.js?_nc_x=Ij3Wp8lg5Kz.
This is not a security measure for weak code to be left unattended. Always get a permanent solution to weak code and secure your websites properly before implementing this strategy
The best tool by far according to my knowledge would be to add multiple javascript files that simply changes the integrity of the page back to normal by refreshing or replacing content. Disabling this developer tool would not be the greatest idea since bypassing is always in question since the code is part of the browser and not a server rendering, thus it could be cracked.
Should you have js file one checking for <element> changes on important elements and js file two and js file three checking that this file exists per period you will have full integrity restore on the page within the period.
Lets take an example of the 4 files and show you what I mean.
index.html
<!DOCTYPE html>
<html>
<head id="mainhead">
<script src="ks.js" id="ksjs"></script>
<script src="mainfile.js" id="mainjs"></script>
<link rel="stylesheet" href="style.css" id="style">
<meta id="meta1" name="description" content="Proper mitigation against script kiddies via Javascript" >
</head>
<body>
<h1 id="heading" name="dontdel" value="2">Delete this from console and it will refresh. If you change the name attribute in this it will also refresh. This is mitigating an attack on attribute change via console to exploit vulnerabilities. You can even try and change the value attribute from 2 to anything you like. If This script says it is 2 it should be 2 or it will refresh. </h1>
<h3>Deleting this wont refresh the page due to it having no integrity check on it</h3>
<p>You can also add this type of error checking on meta tags and add one script out of the head tag to check for changes in the head tag. You can add many js files to ensure an attacker cannot delete all in the second it takes to refresh. Be creative and make this your own as your website needs it.
</p>
<p>This is not the end of it since we can still enter any tag to load anything from everywhere (Dependent on headers etc) but we want to prevent the important ones like an override in meta tags that load headers. The console is designed to edit html but that could add potential html that is dangerous. You should not be able to enter any meta tags into this document unless it is as specified by the ks.js file as permissable. <br>This is not only possible with meta tags but you can do this for important tags like input and script. This is not a replacement for headers!!! Add your headers aswell and protect them with this method.</p>
</body>
<script src="ps.js" id="psjs"></script>
</html>
mainfile.js
setInterval(function() {
// check for existence of other scripts. This part will go in all other files to check for this file aswell.
var ksExists = document.getElementById("ksjs");
if(ksExists) {
}else{ location.reload();};
var psExists = document.getElementById("psjs");
if(psExists) {
}else{ location.reload();};
var styleExists = document.getElementById("style");
if(styleExists) {
}else{ location.reload();};
}, 1 * 1000); // 1 * 1000 milsec
ps.js
/*This script checks if mainjs exists as an element. If main js is not existent as an id in the html file reload!You can add this to all js files to ensure that your page integrity is perfect every second. If the page integrity is bad it reloads the page automatically and the process is restarted. This will blind an attacker as he has one second to disable every javascript file in your system which is impossible.
*/
setInterval(function() {
// check for existence of other scripts. This part will go in all other files to check for this file aswell.
var mainExists = document.getElementById("mainjs");
if(mainExists) {
}else{ location.reload();};
//check that heading with id exists and name tag is dontdel.
var headingExists = document.getElementById("heading");
if(headingExists) {
}else{ location.reload();};
var integrityHeading = headingExists.getAttribute('name');
if(integrityHeading == 'dontdel') {
}else{ location.reload();};
var integrity2Heading = headingExists.getAttribute('value');
if(integrity2Heading == '2') {
}else{ location.reload();};
//check that all meta tags stay there
var meta1Exists = document.getElementById("meta1");
if(meta1Exists) {
}else{ location.reload();};
var headExists = document.getElementById("mainhead");
if(headExists) {
}else{ location.reload();};
}, 1 * 1000); // 1 * 1000 milsec
ks.js
/*This script checks if mainjs exists as an element. If main js is not existent as an id in the html file reload! You can add this to all js files to ensure that your page integrity is perfect every second. If the page integrity is bad it reloads the page automatically and the process is restarted. This will blind an attacker as he has one second to disable every javascript file in your system which is impossible.
*/
setInterval(function() {
// check for existence of other scripts. This part will go in all other files to check for this file aswell.
var mainExists = document.getElementById("mainjs");
if(mainExists) {
}else{ location.reload();};
//Check meta tag 1 for content changes. meta1 will always be 0. This you do for each meta on the page to ensure content credibility. No one will change a meta and get away with it. Addition of a meta in spot 10, say a meta after the id="meta10" should also be covered as below.
var x = document.getElementsByTagName("meta")[0];
var p = x.getAttribute("name");
var s = x.getAttribute("content");
if (p != 'description') {
location.reload();
}
if ( s != 'Proper mitigation against script kiddies via Javascript') {
location.reload();
}
// This will prevent a meta tag after this meta tag # id="meta1". This prevents new meta tags from being added to your pages. This can be used for scripts or any tag you feel is needed to do integrity check on like inputs and scripts. (Yet again. It is not a replacement for headers to be added. Add your headers aswell!)
var lastMeta = document.getElementsByTagName("meta")[1];
if (lastMeta) {
location.reload();
}
}, 1 * 1000); // 1 * 1000 milsec
style.css
Now this is just to show it works on all files and tags aswell
#heading {
background-color:red;
}
If you put all these files together and build the example you will see the function of this measure. This will prevent some unforseen injections should you implement it correctly on all important elements in your index file especially when working with PHP.
Why I chose reload instead of change back to normal value per attribute is the fact that some attackers could have another part of the website already configured and ready and it lessens code amount. The reload will remove all the attacker's hard work and he will probably go play somewhere easier.
Another note: This could become a lot of code so keep it clean and make sure to add definitions to where they belong to make edits easy in future. Also set the seconds to your preferred amount as 1 second intervals on large pages could have drastic effects on older computers your visitors might be using
Related
Is it possible to change the content of document.scripts[0].firstChild with a textual replacement? And in such a way that the changes affect the code.
e.g.
function hamjam() {
console.log("__hamjam__");
}
document.scripts[0].firstChild.textContent = document.scripts[0].firstChild.textContent.replaceAll("__hamjam__", "XXX")
Calling hamjam now should log XXX instead of __hamjam__ (which it does not).
Important, what I try to do is highly experimental and more a proof of concept then something I try to do in production. The goal can be achieved in a really ugly matter, and if it only works with a certain browser is also fine.
And in such a way that the changes affect the code.
No. You can change the text that's in the script tag, but that text is obsolete by the time you do it. It's been parsed into actual program code in memory. Changing it has no effect on that program code in memory. (In fact, you could remove the script tag entirely and it would have no effect — unlike removing CSS resources, which does.)
Here's an example:
const script = document.getElementById("target-script");
script.textContent = script.textContent.replace("Hi there", "I've updated the message!");
console.log("The new script content is:");
console.log(script.textContent);
console.log("But click the button and see what happens.");
<input type="button" id="the-button" value="Click me">
<script id="target-script">
document.getElementById("the-button").addEventListener("click", () => {
const message = "Hi there";
console.log(message);
});
</script>
You've said your example is just a small example of a larger thing, but FWIW, you could replace that function. In very limited situations, that might do what you want (and so probably isn't applicable to your larger pattern).
Here's an example:
console.log("Calling it before the change:");
hamjam();
console.log("Changing it");
let source = Function.prototype.toString.call(hamjam);
source = source.replace(/__hamjam__/g, "XXX");
hamjam = (0, eval("(" + source + ")"));
console.log("Calling it after the change:");
hamjam();
<script id="target-script">
function hamjam() {
console.log("__hamjam__");
}
</script>
But that only works in very limited situations.
Function.prototype.toString has to return a valid representation of the function (which it should do in the normal case, but...)
The function has to be assignable in the scope where you're making the change
It has to not close over things that it relies on (because your new version won't)
...and probably others.
Side note: That (0, eval("...")) may look odd if you haven't seen it before. As you may know, eval has this...special...ability that it works in local scope. But most of the time (in my experience, YMMV), you don't want the code you're evaluating to have access to local scope. The (0, eval("...")) pattern (0 can be anything) breaks the link with local scope, doing the eval at global scope instead. It's called "indirect eval".
I'm creating a custom Chrome extension, which is going to retrieve data about an active tab before sending it to a secondary website.
I've been trying to find a method on how to retrieve the console output for an active tab. chrome.tabs.getSelected seemed promising at first, however, it doesn't offer an output of the console text. I've been digging for couple of hours without much success of finding a method that could give me this info.
Could anyone point me in the right direction please?
Edit:
As a way to keep track of everything I've tried so far, for myself and others, I will add info below.
I've found a possible solution which may work for me. The below code will extend the console methods log, error and warn. I'm currently researching for a method that maybe able to attach this code to the active tab, so I can collect the console outputs in the arrays and then make these available on my extension to be sent over to the secondary website.
I will post more info as I progress through it.
var logs = [],
cLogs = [],
cErrors = [],
cWarns = [],
_log = console.log,
_error = console.error,
_warn = console.warn;
console.log = function () {
for (var i = 0; i < arguments.length; i++) {
logs.push(arguments[i]);
cLogs.push(arguments[i]);
}
_log.apply(this, arguments);
};
console.error = function () {
for (var i = 0; i < arguments.length; i++) {
logs.push(arguments[i]);
cErrors.push(arguments[i]);
}
_error.apply(this, arguments);
};
console.warn = function () {
for (var i = 0; i < arguments.length; i++) {
logs.push(arguments[i]);
cWarns.push(arguments[i]);
}
_warn.apply(this, arguments);
};
console.log('welcome');
console.error({'foobar': ['foo','bar']});
console.warn({'foo':'bar'});
_log(logs);
This issue is significantly harder than it appears.
APIs like chrome.tabs have no access to a tab's console. In fact, no "standard" API does.
One could expect a content script running in the context of the page to be able to access it. However, there's no way to access previous output of the console from a JavaScript context.
The method you quote in your update (creating wrappers around console.* functions) can only capture future invocations of those functions, and won't capture things like errors from the JS runtime itself (e.g. unhandled exceptions or network errors). As such, to access console from an arbitrary tab, you'll need to inject this code into every tab, before it loads, even if you only rarely use it.
It is further complicated by the fact that content scripts do not, in fact, run in the same context. To override console for the page itself, you'll need to inject the script in the page context.
So, to summarize:
You can do it by overriding console.* functions and listening to error event on window object, but it has to be done in page context by a document_start content script injecting code into every page. Extracting this data from the page context will be a challenge in itself.
Downsides:
It hurts overall browser performance.
It won't see some browser-initiated messages that go directly to console.
You can take the big hammer and use chrome.debugger API. This API has the same level of access to the page as the Dev Tools themselves - therefore, it's possible to obtain the full console output history.
Downsides:
You'll need to study the remote debugging protocol, see the official examples.
A very scary warning will be shown in all tabs when the debugger API is used.
All in all, what you're trying to achieve is a hard task with fragile solutions. Perhaps you need to rethink your approach.
We have a use case where we need to block Drupal's core ajax error handling from alerting users (we're handling the error reporting on our own). Previously another developer had commented out a line in the core ajax.js file, to prevent Drupal from spawning the alert box, but I'd like to handle it without touching core.
From the core, drupal.js:
/**
* Displays a JavaScript error from an Ajax response when appropriate to do so.
*/
Drupal.displayAjaxError = function (message) {
// Skip displaying the message if the user deliberately aborted (for example,
// by reloading the page or navigating to a different page) while the Ajax
// request was still ongoing. See, for example, the discussion at
// http://stackoverflow.com/questions/699941/handle-ajax-error-when-a-user-
// clicks-refresh.
if (!Drupal.beforeUnloadCalled) {
alert(message);
}
};
My current fix, is to override the Drupal.displayAjaxError function and change the Drupal.beforeUnloadCalled property that determines whether or not to alert the error:
var ajax_error_backup = Drupal.displayAjaxError;
Drupal.displayAjaxError = function (message) {
Drupal.beforeUnloadCalled = true;
ajax_error_backup(message);
};
My question, is whether or not this is an appropriate fix? I know that I could also override the function and just leave it empty - costing fewer lines, and not invoking another call to the original function (and saving the object I've created by backing up the original in ajax_error_backup).
Am I adding complexity to keep things tidy, or should I just override with:
Drupal.displayAjaxError = function (message) {
//empty
};
To clarify - the desire is to never have this ajax alert occur, so there's not functional difference between my desire to keep things neat/tidy, and just overriding the function with a blank one - there isn't a case where want this alert to succeed.
Thanks in advance for helping this old dog think through something with fresh eyes.
In this case, there isn't one option that seems to be clearly better than the other. It should be handled on a case by case basis, and in this case, either of the methods really is adequate.
I personally opted for using the slightly more expensive method of overriding the function and calling it back, because I felt that it might be somewhat more future-proof:
var ajax_error_backup = Drupal.displayAjaxError;
Drupal.displayAjaxError = function (message) {
Drupal.beforeUnloadCalled = true;
ajax_error_backup(message);
};
If Drupal were to extend the function on their end in the future, there might be another condition that we wouldn't want to override.
Overriding with the empty function would be the cheapest, but would also potentially be a bit heavy handed.
It seems that either approach is valid, and is probably best handled case-by-case.
I am trying to automate the browser using phantomjs. I load a page, supply the login credentials and then want to click on the submit button. As the first step I loaded a page, modified the form values and piped the output to a .html file to see if that works. Here is my code:
var page = require('webpage').create();
var fs = require('fs');
page.onConsoleMessage = function(msg) {
fs.write("/home/phantom/output.html", msg, 'w');
};
page.settings.userAgent = 'SpecialAgent';
//page.open('http://google.com', function(status) {
page.open('https://somewebsitehavingaform.com', function(status) {
if (status !== 'success') {
console.log('Unable to access network');
} else {
var ua = page.evaluate(function() {
document.getElementsByName('id').value="id";
document.getElementsByName('name').value="name";
document.getElementsByName('password').value="password";
console.log(document.body.innerHTML);
});
}
phantom.exit();
});
When i open the output.html, it shows me the form but its empty. I expected id,name and password to be pre-filled. Where i am going wrong here?
First of all, getElementsByName will return an array. In order to set the value of the first input found with that name, you'd need to choose a specific element in it, i.e. the first:
getElementsByName('foo')[0].value = 'bar'
Then, if you change the assignment to use setAttribute it seems to work correctly:
var ua = page.evaluate(function() {
document.getElementsByName('id')[0].setAttribute("value", "id");
document.getElementsByName('name')[0].setAttribute("value", "name");
document.getElementsByName('password')[0].setAttribute("value", "password");
console.log(document.body.innerHTML);
});
According to the Mozilla docs,
Using setAttribute() to modify certain attributes, most notably value
in XUL, works inconsistently, as the attribute specifies the default
value. To access or modify the current values, you should use the
properties. For example, use elt.value instead of
elt.setAttribute('value', val).
Though since you're just writing out the resulting HTML to file, I don't think it should cause you a problem in this instance.
Not sure if Phantom JS is now using the QJSEngine internally, but notice this open ticket on their backlog that might be related to the issue you're getting with dot notation:
QJSEngine is a simple wrapper around V8, mainly for use with QtQml.
Using QJSEngine for the PhantomJS main context might prove to be more
malleable/customizable than the current implementation.
Problems:
…
Automatic property creation when using dot notation does not work with QObjects added to the QJSEngine
(This suggests that QJSEngine isn't the current implementation in use, but was raised 9 months ago, so not sure if it's been introduced since then, so thought it was worth flagging)
I have this tiny little script that I run inside Chrome using Tampermonkey and works great.
However, when I use it in Firefox with Greasemonkey, it shows up on the active list, meaning its matching the page but it doesn't actually execute the code. I know it has to be a simple something I am overlooking but its not hitting me.
var myVar=setInterval(function(){myTimer();},100);
function myStopFunction()
{
clearInterval(myVar);
}
function myTimer()
{
var p1 = "Login";
var p2 = "mode=login";
var x = document.body.innerHTML;
if (x.match(p1) && x.match(p2)){
document.documentURI = "/ucp.php?mode=login";
}
myStopFunction();
}
Script Logic/Function
I am using a timer to prevent the script from triggering over and over in a permanent loop.
It simply detects if I am logged into a phpBB forum or not, if not send me to the login page so I can log in.
I am using document URI so that the location of the original is preserved so upon login, it takes me right back to it.
Often phpBB when you log in, it will take you back to the index page so this preserves my original intent of going to the actual link.
This script works perfectly and as expected on Chrome using TM but on Firefox using GM it doesn't trigger, am I missing something here?
From the Firefox spec:
(document.documentURI)
Returns the document location as string. It is read-only per DOM4 specification.
And, indeed, the latest spec still specifies that this attribute must be read only.
If Chrome lets you write this property, then that is non-standard behavior and maybe a bug.
Use location.assign(), or location.replace(), or just programmatically click the login button -- which often preserves the target page.