Please use the referer when Origin or x-requested-with doesn't exist. about cors-anywhere HOT 15 CLOSED

1. Chrome version? See chrome://version
2. Source code to reproduce the issue?

from cors-anywhere.

@Rob--W : Ok it seems it appends if the code is run as an extension. In that case, an AJAX query doesn't set the Origin header making your proxy blocking the query. However, there is no real way to detect that behaviour.

from cors-anywhere.

@ytrezq Could you use more words to describe the issue? I currently don't see anything actionable here.

from cors-anywhere.

You proxy doesn’t answer requests when the origin header isn’t set.

However, Google Chrome doesn’tOrginwhen the ajax request is done inside a user script.

The result is the same code isn’t cross browser. So it would be nice if you added a fallback instead of thawing an error without the page contents.

from cors-anywhere.

You proxy doesn’t answer requests when the origin header isn’t set.

That is intentional. If the Origin header is not set, then CORS is not needed in the first place, so it's a waste to use CORS Anywhere.

However, Google Chrome doesn’t Orgin when the ajax request is done inside a user script.

You can send a direct request to the URL, without any proxy. If for some reason you really want to use CORS Anywhere (e.g. to bypass geographic restrictions), then you can set the X-Requested-With header.

The result is the same code isn’t cross browser. So it would be nice if you added a fallback instead of thawing an error without the page contents.

The result is cross-browser: Regardless of the browser, if the Origin and X-Requested-With header are both absent, then the request is rejected.

from cors-anywhere.

You can send a direct request to the URL, without any proxy. If for some reason you really want to use CORS Anywhere (e.g. to bypass geographic restrictions), then you can set the X-Requested-With header.

Which imply treating web browsers differently (that’s why I ended up using an another proxy which server the page using the original headers).

The result is cross-browser: Regardless of the browser, if the Origin and X-Requested-With header are both absent, then the request is rejected.

I disagree, some rendering engines will set theOriginheader in the case of userscript, and check for ꜱᴏᴘ relative to the current url in the navbar. Such web browsers will require a ᴄᴏʀꜱ proxy.

from cors-anywhere.

You can send a direct request to the URL, without any proxy. If for some reason you really want to use CORS Anywhere (e.g. to bypass geographic restrictions), then you can set the X-Requested-With header.

Which imply treating web browsers differently (that’s why I ended up using an another proxy which server the page using the original headers).

CORS Anywhere preserves the response and headers (except for cookies). The restriction for the request header exists to prevent users from using CORS Anywhere as an insecure casual proxy (insecure because cookies and client-side storage would then be shared by all proxied sites).

I disagree, some rendering engines will set theOriginheader in the case of userscript, and check for ꜱᴏᴘ relative to the current url in the navbar. Such web browsers will require a ᴄᴏʀꜱ proxy.

And you obviously know which browsers need CORS... So, what is wrong with only using CORS Anywhere for the browsers that need it, and use direct requests for other browsers?

AFAIK, all modern browsers support cross-origin requests in their extensions/userscripts: Firefox (xpi), Safari (safariextz), Chrome (crx), Opera extensions (oex), Opera extensions (nex), Firefox (Greasemonkey), Chrome/Opera (Tampermonkey). The only time I needed a CORS proxy was for a UserJS script (Opera 12-), but that was many years ago.

from cors-anywhere.

CORS Anywhere preserves the response and headers (except for cookies). The restriction for the request header exists to prevent users from using CORS Anywhere as an insecure casual proxy (insecure because cookies and client-side storage would then be shared by all proxied sites).

Then you don’t have a good understanding. The breach is only about cookies and dynamic resources, not static ones (and in fact, even Yahoo’s yql doesn’t implement that restriction).

And you obviously know which browsers need CORS... So, what is wrong with only using CORS Anywhere for the browsers that need it, and use direct requests for other browsers?

Because User Scripts aren’t server with a User Agent ʜᴛᴛᴘ header ?

AFAIK, all modern browsers support cross-origin requests in their extensions/userscripts: Firefox (xpi), Safari (safariextz), Chrome (crx), Opera extensions (oex), Opera extensions (nex), Firefox (Greasemonkey), Chrome/Opera (Tampermonkey).

Everything you’re citing here is Greasemonkey based, I need to avoid starting after page load since page loading of the target website only finish to load in Google Chrome and blink based Opera (several elements last to load indefinitely in all other browsers preventing the script from starting).

from cors-anywhere.

CORS Anywhere preserves the response and headers (except for cookies). The restriction for the request header exists to prevent users from using CORS Anywhere as an insecure casual proxy (insecure because cookies and client-side storage would then be shared by all proxied sites).

Then you don’t have a good understanding. The breach is only about cookies and dynamic resources, not static ones (and in fact, even Yahoo’s yql doesn’t implement that restriction).

YQL's responses are wrapped in JSON/XML, so that cannot mistakenly be parsed as a web page. CORS Anywhere does not modify the response body at all, so if a user was able to directly visit any site, then users could try to (successfully) log in to a site on one domain, and the browser will share the cookies / local storage with other sites, because the domain for security decisions is cors-anywhere.herokuapp.com, not the proxied domain.

By the way, the demo at cors-anywhere.herokuapp.com is a demo. Nothing stops you from hosting CORS Anywhere yourself with custom settings (in fact, I encourage this by putting the source code and documentation on Github). The default server is here, remove requireHeader and the proxy will behave as you want: https://github.com/Rob--W/cors-anywhere/blob/master/server.js (but note the potential security issues as I mentioned above).

And you obviously know which browsers need CORS... So, what is wrong with only using CORS Anywhere for the browsers that need it, and use direct requests for other browsers?
Because User Scripts aren’t server with a User Agent ʜᴛᴛᴘ header ?

If you really want to resort to browser sniffing, then navigator.userAgent is your friend.

AFAIK, all modern browsers support cross-origin requests in their extensions/userscripts: Firefox (xpi), Safari (safariextz), Chrome (crx), Opera extensions (oex), Opera extensions (nex), Firefox (Greasemonkey), Chrome/Opera (Tampermonkey).

Everything you’re citing here is Greasemonkey based,

What I listed were the extension platforms of the browsers, and some user script managers. Is there anything special about your platform such that it behaves radically different from the ones I listed?

I need to avoid starting after page load since page loading of the target website only finish to load in Google Chrome and blink based Opera (several elements last to load indefinitely in all other browsers preventing the script from starting).

How is this relevant for the discussion?

from cors-anywhere.

CORS Anywhere does not modify the response body at all, so if a user was able to directly visit any site, then users could try to (successfully) log in to a site on one domain, and the browser will share the cookies / local storage with other sites, because the domain for security decisions is cors-anywhere.herokuapp.com, not the proxied domain.

Personally, I would be very worried about letting my passwords readable by the proxy mainteners who I don’t if I can trust .
No to mention this can easily be detected by getting a look at the ᴜʀʟ.

And for that reason (in the case someone create such Proxy), no browser will send the Cookie header in an ajax request if theAccess-Control-Allow-Originheader contains a wildcard in the OPTION ʜᴛᴛᴘ response.

By the way, the demo at cors-anywhere.herokuapp.com is a demo. Nothing stops you from hosting CORS Anywhere yourself with custom settings (in fact, I encourage this by putting the source code and documentation on Github).

Due to the primary purpose of the script, the answer is legally no (and probably for your demo too). And more generally, every solutions that used a dedicated server part were closed (though I wasn’t involved at all in their creation/maintenance) (the design of a complete client solution is needed to avoid that). This also for that reason I now only maintain that script for myself.
But I won’t discuss this here adn simply chose.

What I listed were the extension platforms of the browsers, and some user script managers. Is there anything special about your platform such that it behaves radically different from the ones I listed?

Except solid ᴀᴘɪs for controlling when the script is loaded. Among the choices of extensions I recommend. I keep Greasmonkey UserScript as a Fallback (which only works on Blinks).

How is this relevant for the discussion?

This is relevant in that in most cases native cross origin requests isn’t supported.

from cors-anywhere.

What I listed were the extension platforms of the browsers, and some user script managers. Is there anything special about your platform such that it behaves radically different from the ones I listed?

Except solid ᴀᴘɪs for controlling when the script is loaded.

I really don't see the relation between you not having control over when a script is loaded, and the ability to make cross-origin requests.

Among the choices of extensions I recommend. I keep Greasmonkey UserScript as a Fallback (which only works on Blinks).
This is still easier than maintaining an extension for each browsers.

If you're using Greasemonkey, then you should be able to use GM_xmlhttpRequest (unless you use @grant none; in that case, just add @grant GM_xmlHttpRequest).

So far, I've showed several alternatives that doesn't require me to change the settings for CORS Anywhere. Even if you don't want to rely on platform-specific APIs or host the proxy yourself, then sure enough you should not have any issues with setting the X-Requested-With header, do you?

• Set the X-Requested-With request header
• Use direct requests when available (either via platform-specific APIs such as GM_xmlHttpRequest, or via extension-specific permissions)
• Self-host CORS Anywhere and remove the requireHeader configuration option.

from cors-anywhere.

I really don't see the relation between you not having control over when a script is loaded, and the ability to make cross-origin requests.

Because the implementations that allow (while still not using extensions) to control when the script is loaded tend to not support native cross origin requests.

So far, I've showed several alternatives that doesn't require me to change the settings for CORS Anywhere. Even if you don't want to rely on platform-specific APIs or host the proxy yourself, then sure enough you should not have any issues with setting the X-Requested-With header, do you?

All of your alternatives are Greasmonkey derivates. In the case of that script they will work only after on blink based web browsers.
(because page loading need to end in order to get the script be started)

from cors-anywhere.

So far, I've showed several alternatives that doesn't require me to change the settings for CORS Anywhere. Even if you don't want to rely on platform-specific APIs or host the proxy yourself, then sure enough you should not have any issues with setting the X-Requested-With header, do you?

All of your alternatives are Greasmonkey derivates. In the case of that script they will work only after on blink based web browsers.

Are you referring to my comment at https://github.com/Rob--W/cors-anywhere/issues/13#issuecomment-189499317 ? That comment showed several examples of implementations where direct cross-origin requests are supported. So far you've only claimed that your script cannot make cross-origin requests, but without naming any platform or environment where that happens.

Anyway, by "alternatives", I was not referring to that comment. I listed three bullet points, and emphasized that regardless of the environment, you should not have any trouble with setting the X-Requested-With request header.

E.g. with XMLHttpRequest:

var x = new XMLHttpRequest();
x.open('GET', 'https://cors-anywhere.herokuapp.com/https://example.com');
// I put "XMLHttpRequest" here, but you can use anything you want.
x.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
x.onload = function() {
    alert(x.responseText);
};
x.send();

from cors-anywhere.

can cors-anywhere set the referer too? would be nice something like:

https://cors-anywhere.herokuapp.com/?headers={referer:"http://example.org"}

or to interpret a custom header like "myheaders:" in the post

from cors-anywhere.

@Zibri Not in the public demo. If you self-host CORS Anywhere, then you can use the setHeaders option in the server to add the Referer header.

from cors-anywhere.