I wrote an extension that works both on Firefox and on Chrome. That extension injects some code on the page that also does a Get - Request on the same site.
I am on https://example.com/Posts/1234 and try to call another url from the same host:
var docUrl=document.location.href;
$.get(docUrl + '/mentionable.json?q=test', function (response) {
// do something
});
(So the complete url called is https://example.com/Posts/1234/mentionable.json?q=test)
In the chrome extension this works just fine. When I try to run the same code as a Firefox web-extension instead I retrieve a 401 unauthorized response. So my guess would be that chrome sends the authorization-cookie from the current visited site while Firefox does not.
Any way to tell Firefox to use the current authorization?
I found the solution. Firefox requires the following entry in the permissions of the manifest.json:
"https://*/*"
(or the URL you want to connect to) even if it's the same host as the site the extension-js is on. Chrome works without this entry.
Related
Scenario:
I have parent site A domain A that embeds an iframe with domain B...note that I have control of both sites. Im calling postMessage from site A that posts some information to be stored as cookie in iframe domain B. The iFrame will listen to the postMessage event and set cookie accordingly.
Domain A:
var frame = document.getElementById('exampleFrame');
frame.contentWindow.postMessage({"age":28}, '*');
Embedded iframe domain B:
window.addEventListener('message', messageReceivedEvent, false);
function messageReceivedEvent(e) {
document.cookie("age=" + e.data.age + ";");
console.log(document.cookie);
}
console.log(document.cookie) returns nothing
The issue here is that, once i set the cookie in the messageReceivedEvent, it seems like the cookie is not stored in domain B. Did I missed out something?
Note: This issue only happened in latest Google Chrome version, Firefox works fine.
Chrome handles cookies differently.
See Mozilla Document.cookie Example #1:
it works perfectly in Firefox
does not work in Chrome
See this SO thread about chrome cookies.
Also, with iFrames other people reported this Chrome "bug" here:
thread on bugs.chromium.org
or here support.google.com thread
Not sure how to solve it, but maybe use localStorage instead?
Update: As of Sep 7 2019 (Firefox 79), this is no longer the case. Must have been a mistake in FF 51.
This question is for the Firefox devs/pros out there. I can't find any info on this.
I've longed assumed XMLHttpRequest (XHR) and similar APIs such as the new Fetch API are not supposed to work locally (i.e. file uri), and only work on http or https uri scheme. It's supposed to be some big security risk.
In the past, the only way to circumvent this in Firefox was changing security.fileuri.strict_origin_policy to false in about:config. To my surprise, I can use both XHR and Fetch API without changing that setting in the latest Firefox.
Why does it start working out of nowhere on Firefox 51.0.1? Is this a bug, a new standard, or some vendor-specific thing? Is Chrome going to follow along with this?
To see what I mean, create an index.htm with some JS code and a test.txt with some text, and open the index.htm in Firefox locally.
Put this in the HTML:
<script>fetch("test.txt").then(function(response) {
return response.text();
}).then(function(text) {
alert(text);
});</script>
In Firefox it should show an alert box with the contents of the text file. In Chrome/Canary, it will complain:
Fetch API cannot load file:///R:/test/test.txt. URL scheme must be "http" or "https" for CORS request.
I'm attempting to port a Chrome extension to Edge. The Chrome extension works fine, and all HTTP requests are working as expected. When these same requests fire in the port, I get this error:
XMLHttpRequest: Network Error 0x2efd, Could not complete the operation due to error 00002efd.
This issue seems to pop up for a lot of Microsoft stuff, including Windows Phone. Maybe there is a similar answer to my issue for this extension, but I'm permitting ALL URLs in my manifest...
This is the request:
$http.get(url)
.then(function () {
})
.catch(function () {
var args = arguments;
});
I've also tried the jQuery way:
$.ajax({
url: url,
success: function () {
},
error: function () {
var args = arguments;
}
});
I can't share the exact URL because it is part of our business architecture, but the Chrome extension consumes it just fine. If I open the URL directly in a browser (Edge or Chrome) it shows the result just fine... I'm at a loss. I know the error means the request can't connect, but why? And how do I fix it?
Seems to be a known bug that hasn't been fully triaged as of 2016-10-07.
In another bug report Microsoft mysteriously says "This is by design as extensions don’t support loopback" and closed it as such. That would certainly be an incompatibility with the Chrome model.
The symptom seems to be that connections to sites that are considered part of the Local Intranet by Windows network stack are denied as part of an aggressive XSS prevention policy.
There is definitely nothing you can do on the extension side until this is resolved by MS. If anything, extension code needs to be privileged enough to do this, even if that breaks their compartmentalization model.
It's possible that you can do some environment changes though. I would experiment with Internet Options for "Local intranet" zone, for example setting Protected Mode on, disabling that for Internet zone, or more likely somehow making sure the site isn't considered intranet. A domain name instead of an IP address may also help "fooling" Edge that it's not intranet.
I need to query a third-party site with ajax. To do so I need cookies, which I retrieve by loading the site's page in a hidden frame. However, I just saw that IE (at least 11) blocks cookies set in frames if the site doesn't provide a P3P policy.
To work around that, I initially thought opening the site in a popup then closing it. But it seems impossible, as the return value of a window.open is null if the url is not from the same domain.
Here's some test code:
var foo = window.open(url);
setTimeout(function(){
foo.close(); // fails in IE as foo is null if url is 3rd-party
}, 2000);
I've seen restrictions, such as Window.close can only close windows created with js (or asks confirmation), but I haven't seen anything regarding cross-domain such as my case. BTW, there's no issue with FF and Chrome. Is there any way to do that?
Ok, so I finally got it. It has nothing to do with same origin policy. The catch is I was testing the above code in a page accessed through a http://localhost/ url. If I access the same page with http://127.0.0.1/ instead, the foo variable is not null and the popup can be closed.
If anyone has any idea why some restrictions in IE apply on localhost and not on 127.0.0.1, you're welcome.
I try to load a json file from a server with XMLHttpRequest.
But I only get status==0 and the chrome dev console says: "(canceled)"
I can reproduce this with this (simplified) code:
var httpReq = new window.XMLHttpRequest();
httpReq.onreadystatechange = function(data) {
if (httpReq.readyState == 4) {
alert(httpReq.status);
}
}
httpReq.open("GET", "http://dl.dropbox.com/[...]/data.json");
httpReq.send(null);
This code stops working, as it is in the extension context.
The same function is also used to load files from an other server (also crossdomain), without any problem.
Here is the manifest part:
"permissions": [ "http://theOtherWorkingServer.com/*", "http://dl.dropbox.com/*", "https://dl.dropbox.com/*" ],
I've read a lot about this problem, but found no working solution.
(The main page is not reloading and also not redirected at this time)
Any suggestions??
The error you're getting is a sign that a redirect was performed, to an URL which does not match any of your declared permissions.
To verify my statement, add the *://*/* or <all_urls> permission to the manifest file, and you will notice that the request completes successfully.
To determine which redirects are followed, follow the following steps:
Open the developer tools, go to the Network tab.
Paste the URL in the omnibox, and hit enter
Read the URLs in the developer tools.
As you can see in the previous picture, dl.dropbox.com actually redirects to dl.dropboxusercontent.com. This domain has to be added to the permission section of your manifest file, to fix the problem:
"permissions": [
"http://theOtherWorkingServer.com/*",
"*://dl.dropbox.com/*",
"*://dl.dropboxusercontent.com/*"
],
(the the wildcard at the scheme matches http and https - see match patterns)