Is it possible to disable AJAX without disabling JavaScript completely?
If you are using Firefox, you could accomplish this with GreaseMonkey. (https://addons.mozilla.org/en-US/firefox/addon/748)
GM is a framework for applying scripts to some or all of the pages you visit. I have GM scripts that disable google-analytics downloads (because they slow things down), and which disable google-click-tracking on google result pages (because it bothers me that they are doing that).
Here is my google-click disable script:
// ==UserScript==
// #name Google Clk
// #namespace googleclk
// #description Disable Google click tracking
// #include http://*google.com/*
// ==/UserScript==
// Override google's clk() function, which reports all clicks back to google
unsafeWindow.clk = function(url) {} // { alert(url); } // I use this to test.
By doing something similar with XMLHttpRequest (and other functions) you can effectively disable them. Of course, you may completely break the page by doing this, but you already knew that.
You can replace the browser tool to make AJAX (XMLHttpRequest object) with your own that does nothing.
XMLHttpRequest = function(){}
XMLHttpRequest.prototype = {
open: function(){},
send: function(){}
}
Be sure that your replacement code executes before any AJAX call.
This will work for any browser that implement AJAX through the XMLHttpRequest object but will not work for IE. For IE, you may have to overload the CreateObject() function if possible...
In IE this can be done with: Tools -> Internet Options -> Advanced Tab -> Scroll down to Security -> Uncheck 'Enable Native XMLHTTP Support'.
http://msdn.microsoft.com/en-us/library/ms537505%28v=vs.85%29.aspx
AJAX is simply the usage of the XMLHttpRequest function in Javascript. Depending on your browser, you may be able to lock down access to this function through your security settings.
At least with Firefox, you could disable it either through using a custom Extension.
This is a late comment on a question that has already been answered, but for the benefit of people coming in from Google:
With the Tab Permissions extension for Firefox you can disable JavaScript for a particular tab (as opposed to globally for all tabs) with a right-click context menu. I configured the "Permissions" menu item to toggle "Redirect" and "JavaScript," so if I stumble onto a page that has annoying refreshes and AJAX, I can quickly and easily shut down the bandwidth activity of the misbehaving tab without affecting the JavaScript on my other open tabs.
Additionally to the Firefox suggestion, you can do it in IE as a side-effect of disabling ActiveX. Also on IE7+ you have to disable the ‘Native XMLHttpRequest’ option.
No more than you can disable any other function - there may be some kludges or hacks to be found that could interfere with or break javascript, but we would hope not to find such vulnerabilities.
I'll take a wild stab in the dark and guess that you're trying to stop Ajax in untrusted user input of some kind? Your best bet in that case would be to avoid over-specifying your search parameters by mentioning Ajax, rather, search for 'sanitize javascript', 'user javascript safe'... that kind of thing.
No. AJAX is just a particular use of javascript.
If you could block the particular function call back to the server you might be able to do it, but you would probably have to edit your browser.
I assume you want to do this from the client end... Can you list some more specific goals? What is the expected outcome?
Related
I'm trying to make a Bookmarklet to grab an id value from the Clipboard, and navigate to a URL that is built with that id.
javascript:(function(){
window.location="index.php?module=Accounts&action=DetailView&record="
+ clipboardData.getData('Text');
})()
(this is only supposed to work when clicked on a specific site that is expecting that URL form)
The basics of the Bookmarklet are working fine, the tricky part is getting the Clipboard value, because clipboardData is not working.
I am using Firefox v64 (although I would like this to be generic across more browsers, at least modern ones).
Now, upon searching about this issue I realize what I'm trying to do is not as simple as it seems - clipboard API's in browsers are a tricky issue. I found several answers about this, the best one seems to be this:
JavaScript get clipboard data on paste event (Cross browser)
I also tried this one but couldn't get it to work either: https://stackoverflow.com/a/27908501/1189711
My question here is: are any of those techniques applicable in a Bookmarklet? If so, I would appreciate some help with this. My skills in Javascript are too low to understand how to translate these answers to my case - namely the asynchronous stuff.
PS - if someone wants a place to test this, just put 84f1bb99-7017-e8dc-94f9-5c179da9f102 in your clipboard and try it on this demo site, credentials will/will.
Clipboard copy cannot works from scripts. It must comes from an user action.
Similary, in the same way, you can't call a fullscreen from a bookmarklet.
From the Firefox console:
document.execCommand(‘cut’/‘copy’) was denied because it was not
called from inside a short running user-generated event handler.
I try this method and it works:
SAME WINDOWS:
javascript:location.href='https://www.ricerca.com?search%27+escape(location.href)
NEW WINDOWS: (by https://9to5answer.com/window-location-href-and-window-open-methods-in-javascript)
window.open()
javascript:window.open("https://www.ricerca.com?search="+window.getSelection());
How do you disable pushstate for Chrome (for testing purposes)?
Bonus if you know of a plugin that makes it easy to toggle :)
I'm using davis.js for my pushstate logic.
history.pushState = function (){};
//An empty function so if it is used, it doesn't throw any errors
Put that in the console. Tada! You can easily make a Chrome extension that executes that on a page using a Content Script.
The reason your Davis.js routes are still working is because when you click a link it runs your routes directly, since there is no onPushState event, you should find though that using the back and forward buttons no longer trigger your routes.
If you want to emulate what happens in a browser that doesn't support pushState you can fool around with how Davis.js checks for support. This is done in the Davis.supported function.
You can override that function to always return false, which is what would happen normally in a browser that doesn't support pushState. If you wanted to you could wrap this up into a Davis.js extension, see the block iOS extension as an example.
I am using a JavaScript to track the activities of users on my page upon unloading that very page. Consider the following simplified dummie-script to simulate what I am doing on unload:
$(window).unload(function() {
$.get("http://www.google.de/images/srpr/logo3w.png");
});
The image URL in that case serves as a holder for tracking data.
The image is requested in some browsers (e.g. Firefox 3) and isn't loaded in others (e.g. Firefox 6) when closing the browser window.
Probably isn't the way it should be done; anyhow I would like to hold on to it as long as I could make a statement on how reliable the unload-event is.
Any experiences on this?
I have some experience with that and I would recommend a slightly different approach like this:
$(window).unload(function() {
new Image().src = "http://www.google.de/images/srpr/logo3w.png?timestamp="
+ new Date().getTime();
});
The challenge is that if you are making an AJAX-call at unload, you should use synchronous mode. With normal async-mode, it may not succeed at all (for instance in Chrome).
But in this case, a trick using image is just as reliable because the communication is one way only. That works for GET but if you need to POST something then sync-mode is the only option.
I need to be able to make an event such that every time a user loads a new page and closes firefox, I need it to call a method in my C# application that takes care of maintaining the user model. I know for sure I need to create some type of firefox extension where I use javascript to check such an event. However, I have no idea how I am going to integrate my C# application with the firefox extension. Can someone provide me with some guidance?
I'll help you out with the parts of the question that I'm familiar with (Javascript based add-ons), and offer some suggestions for the other parts. Here goes nothing!
Add-ons
Firefox add-ons easily provide the tools you need to detect page loads and opening / closing firefox.
To detect page loads you can register a listener to the DOMContentLoaded event in window.
window.addEventListener("DOMContentLoaded", function(event){
var url = event.originalTarget.location.href;
alert("Oh yeah, a document is loading: " + url);
}, false);
Alternatively, you can register a nsIWebProgressListener to listen for location changes. This probably closer to what you want, since DOMContentLoaded is also triggered for iframes.
var listener = {
//unimplemented methods (just give functions which do nothing)
onLocationChange: function(aWebProgress, aRequest, aLocation){
var url = aLocation.asciiSpec;
alert("Oh yeah, a the location changed: " + url);
}
};
gBrowser.addTabsProgressListener(listener);
To detect firefox open / close you need to first understand how firefox add-ons work with respect to multiple windows. When a new window of firefox is launched, you basically have 2 separate copies of your code running. So, if you care about firefox windows being opened and closed you can simply do:
window.addEventListener("load", function(event){
alert("Looks like you just opened up a new window");
}, false);
window.addEventListener("unload", function(event){
alert("Awh, you closed a window");
}, false);
But, most likely you want to detect opening / closing firefox as an entire application. This is achieved using a code-sharing mechanism called Javascript Modules. Javascript modules are loaded just once for the lifetime of the application. So, they enable you to share information between windows. Simply counting the number of windows opened and closed should be sufficient for this functionality.
var EXPORTED_SYMBOLS = ["windowOpened", "windowClosed"];
var windowsOpened = 0;
function windowOpened(){
if( windowsOpened === 0) {
alert("The first window has been opened!");
}
windowsOpened++;
}
function windowClosed(){
windowsOpened++;
if( windowsOpened === 0) {
alert("The last window has been closed!");
}
}
Then you can simply attach the aforementioned event handlers to call these 2 methods from their corresponding load and unload events.
So, this is all great and everything, but now you have to twiddle with the details of getting a baseline Firefox add-on setup. Fortunately, Mozilla has provided a handy Addon Builder to ease this. All the code about (except the Javascript module) should be placed in the ff-overlay.js file (assuming you use the linked builder).
C# communication
I'm a little less knowledgeable about the interprocess communication with C#. However, maybe I can point you in the right direction and let the smart people at SO fill in the rest.
I believe COM Objects are a method of communication between processes on Windows. So, you could build in a Binary Component to your add-on to perform the communication. However, as far as I understand it, setting up binary components is much more difficult than a standard javascript-based add-on. Either way, Mozilla provides a guide for setting it up in Visual Studio.
If you want to stay away from binary components you are left with the javascript enabled components of the SDK. This includes socket communication, files, pipes, a sqlite database etc. This SO question addresses exactly the question you're asking. If it were me, I would choose them in this order.
Sqlite Database
Named Pipes
Sockets
(1) because there is a lot of code samples available for this, and would be easy to implement on both sides. (2) because this would be the way I'd implement IPC if I were given full control of both sides of the application. (3) is last because I hate that crap (maybe I'm biased from Distributed Systems in college).
tl;dr
The page load stuff should be pretty simple. Check out the Addon Builder to get going with a FF addon, and here to see about detecting page loads.
The C# communication is doable, and addressed in this SO Question. I'd do it with a sqlite database for ease if it were me.
I have just been altered to the fact that a user of my website is using a very old browser which does not run jquery (in this case Safari 1.x) and as a result can not access the login panel which uses jquery's slideToggle function.
Can anyone think of a fix which detects whether a browser is able to use jquery - and if not make that link go to a different page rather than showing the login panel?
You could a little conditional check like
if(!'jQuery' in window) {
// jQuery is not available
}
or, if Safari 1.x doesn't know about the IN operator (I'm not sure) use
if(!window.jQuery) {
}
I think there are alternative answers to this, but for me, I would have to weigh up the time it will take you to support his obsolete browser (I'm sure there may be other things inside the site), versus the payback to you...
In the plain HTML source code for the the href= of the login link, set that to a plain HTML login page.
Using jQuery, attach the click handler to the link, if this part fails, thats ok, the browser will just follow the href in the link to the plain login page, allowing your old-browser-user to login still.
$(document).ready(function(){
$('#login_link_id').click(function(){
// Your code here
});
});
If you use javascript/jQuery you should ALWAYS ensure your site works perfectly without it. In this case if you have a login popup box; you probably assign a click event assigned after the DOM has loaded.
What you should do is ensure that if jQuery isn't present the link loads a "normal" login webpage as opposed to the popupbox. I use something similar to this:
Log in
<script>
if(!'jQuery' in window) {
$(document).ready(function(){
//assign on click event to loginlink
});
}
</script>
If jQuery doesn't exist then login.html will be opened normally.
Wow, seriously?! Safari 1.x?? Anyhow, try this...
var isJQSupported = false;
$(function() { //shorthand for document.ready
isJQSupported = true;
//your usual code
});
if (!isJQSupported) {
window.location = "http://www.apple.com/safari/download/";
}
To me it sounds like safari 1.X has problems with jQuery internally. Which means simple checks like whether $ exists in the global space or whether $(function) does anything are not going to help.
The most likely root cause will be that javascript throws an error in loading of jQuery itself which will then stop the rest of your javascript code from execution.
There are four viable options here.
Either make the website work with noscript. Replace your login control with pure HTML and postbacks and ask the user to turn javascript off. This option is useful since you won't be fixing the issue for safari 1.x problems specifically.
You can make javascript check for safari 1.X and other non-supported browsers and only load jQuery through script tag injection or ajax if your user is using a supported browser. If the user is using a browser not compatible with jQuery then you can instead use plain javascript.
Get a copy of safari 1.x and see why jQuery breaks. Then fix it and ask for it to pulled into the release of jQuery 1.5. This relies on the fix being something that does can be done without hacking and that the jQuery team agrees is worth adding in.
Ask the user to use a compliant browser.
There might be some more options. I would personally lean towards asking the user to use a compliant browser because supporting Safari 1.x is ridiculous.
This seems like a case where progressive enhancement is needed.
You have to do multiple checks
see if $ exists
see if $.fn exists
[not sure if needed] check if $.support is a function
check for feature support as needed with $.support() http://api.jquery.com/jQuery.support/
At the end of the check, when jQuery reports that features you need are present - the rest of the script can run.
If you're not sure which features mentioned in the support you use, then this might need a single test on Safari 1.x to see what are the values returned by $.support(), but that is what your nasty old-browser-user can do for you (if you prepare code and publish) and report the resulting text. Then you compare the list with other [old] browsers that are accessible and determine features that are required.
The easy way would be to require everything and cancel all scripts if suport for any feature is missing. This will also rule out IE6 and IE7 and opera below 9.something and firefox below 2.0 or including - I'm not sure.
Use a server side language to detect if it's the old safari based on user-agent and load a different javascript file