CORS issue on GitHub when running git-receive-pack - javascript

I am trying to make the following requests on GitHub using a Chrome extension:
GET github.com/<user>/<repo>/info/refs?service=git-receive-pack
POST github.com/<user>/<repo>/git-receive-pack
Doing so, I receive a Bad Request Error (400). My understanding is that the error is due to the CORS policy. Actually, if I proxify the URL using CORS proxy servers (like this), there is no issue.
Is there any way of handling this CORS issue in the Chrome extension?
P.S. If I use the extension to make the same requests on GitLab (without using a proxy server), there is no issue.

Related

Bypassing CORS issue in Chrome [duplicate]

This question already has answers here:
Disable same origin policy in Chrome
(35 answers)
Closed 1 year ago.
We are facing an issue where using Chrome request via XMLHTTPRequest is getting failed with below error:
Failed to load <server url>: No 'Access-Control-Allow-Origin' header
is present on the requested resource. Origin '<client domain>' is
therefore not allowed access.
This error is Chrome specific since we are not getting this issue in IE. Is there anyway to bypass this error in JavaScript.
Basically, for development purposes only, you can start the Chrome Browser in relaxed mode using the disable-web-security flag:
Here's how to do it on windows (Credit to https://alfilatov.com/posts/run-chrome-without-cors/)
Right click on desktop, add new shortcut
Add the target as "[PATH_TO_CHROME]\chrome.exe" --disable-web-security --disable-gpu --user-data-dir=~/chromeTemp
Click OK.
The directory in 'user-data-dir' must have read/write permissions for Chrome.
You will get a warning banner in Chrome notifying about reduces security, because that is actually what you have here. USE ONLY FOR TESTING.
Note: This answer builds on the link-only answer by Franco Fontana which was deleted because of link-only but the link actually helped me.
No, fortunately there is not.
The same-origin policy is an security concept implemented by browsers to prevent Javascript code from making requests against a different origin/domain than the one from which it was served. So enabling developers to bypass this from Javascript would be a bad thing.
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application makes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.
Source: Cross-Origin Resource Sharing (CORS)
If you're in control of the API:
Add an Access-Control-Allow-Origin header containing the domain your requests are originating from.
If you're not in control of the API:
Ask the developer of the API to have your domain added to an Access-Control-Allow-Origin header.
EDIT:
Adding the correct header will not 'make the request an OPTIONS request while the server only accepts POST'.
The OPTIONS request is a preflight request to check to see if the CORS call can actually be made. If the preflight request has the correct header, the POST request will follow as you can see in the image below:
You can find all of the basic CORS information in the article Understanding CORS
Although its limited, can try to use CORS anywhere https://github.com/Rob--W/cors-anywhere or the chrome extension here that allows you to bypass CORS (make sure you turn this off when not testing as it will cause issues with requests from other websites)

How to prevent sending Origin HTTP header in Chrome?

Situation:
I have a production web server, let's say https://example.com, configured with CORS with limited set of allowed origins. The set does NOT include localhost origins.
On localhost, developers develop a page/module/whatever that needs to call the production web server via AJAX (even during development). To do that, they run Chrome with CLI arguments --disable-web-security --user-data-dir=chromeNoCors so that Chrome would send AJAX without Origin header.
The problem is that only GET requests are sent without the header. POST requests still contain the header, therefore the production server compares the header value (http://localhost:5678) with allowed set of origins and forbids access to requested resource.
Question:
Is it possible to somehow prevent sending of Origin HTTP header altogether?
I'm aware that there's a workaround to solve this situation by allowing "localhost" (or some specific host that developers will have to add to their /etc/hosts) to the set of allowed origins on production server but I'd like not to do this if possible.
if you guys use chrome try this extension
https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa
you can modify requests on the fly,even headers
I recommend that you setup a simple "proxy server" (short node.js or python script would suffice). Have this server forward all requests to your remote API server but delete the information about the origin in headers. This is a matter of simple regular expression.
This is simple solution that will be portable to different servers. On AJAX side, all you need is to change the hostname to localhost or IP of your testing proxy server.

Angularjs $http get fails, but request is succesful in postman and browser

I'm trying to access the Adobe TypeKit API's via javascript, using AngularJS.
Using $http.get(https://typekit.com/api/v1/json/kits?token=myToken) fails on authenticated requests, with error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
If I use $http.jsonp(...) un-authenticated requests are succesfull, this is probably due to Adobe's CORS policies, but as stated in the typekit documentation
For security reasons, authenticated API requests are currently unavailable with callbacks.
So, using jsonp, I can't access many of the endpoints provided by the API's.
What I don't understand is that the same exact request that fails in angular, succeds if I execute it with postman or with chrome itself. I tryied setting the request headers exactly the same as in postman, but didn't work. Tried all sorts of headers settings, but nothing changed.
Any thoughts?
can you disable the chrome web security and then give it a try.To disable the web security open your terminal and type the following /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --allow-file-access-from-files --allow-file-access --user-data-dir=~/chrome-test/ spec/runner.html

Can't get results from elasticsearch server using JS

I guess the question says it all, but the thing is that there are some anomalies here :|
When javascript tries to fetch the search results I get this error:
Firefox(Firebug):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:9200/index/type/_search. (Reason: CORS request failed).
Chrome:
POST http://localhost:9200/index/type/_search net::ERR_CONNECTION_REFUSED
This is a totally anticipated result, so I googled the solution and found it.
So I added the following lines to the config:
http.cors.allow-origin: '*'
http.cors.enabled: true
And it kinda fixed the problem. Here's the strange part: The app is on a web server, which I access using, let's say, http://whateverdomain.com. So the origin of the javascript would be http://whateverdomain.com and not localhost, thus the problem. Well if that's the case, how come I can interact with elasticsearch, on the remote server, using Sense on my local machine? Isn't my global IP considered cross-origin????
It might be of importance to mention that in sense, i access the server using its IP.
The problem was that when I initialized elasticsearch-js, i used the default host, unchanged, which was localhost, and localhost on js means my local machine.
Changing that to my domain solved the problem.

How does Firefox extension app RESTClient avoid CORS?

I am trying to make a simple POST request and I am still unsuccessful.
Headers change from
Encoding: UTF-8 Http-Method: POST Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
to
Http-Method: OPTIONS
Content-Type:
I understand that when I try to access my server using Google Closure XhrIo , it causes preflight and fails my POST request.
But Firefox extension app RESTClient and also a similar Chrome app can access using XMLHttpRequest and they don't cause preflight. How and why ?
PS: I am not a JS pro and I fail to understand the intricacies of this code http://code.google.com/p/restclient/source/browse/extension/chrome/content/restclient.js.
Any help appreciated
Eddie.
Found this piece of valuable information on HTML5Rocks.com
CROSS-DOMAIN FROM CHROME EXTENSIONS
Chrome extensions support cross-domain requests in a two different ways:
Include domain in manifest.json - Chrome extensions can make cross-domain requests to any domain if the domain is included in the "permissions" section of the manifest.json file:
"permissions": [ "http://*.html5rocks.com"] The server doesn't need to include any additional CORS headers or do any more work in order for the request to succeed.
CORS request - If the domain is not in the manifest.json file, then the Chrome extension makes a standard CORS request. The value of the Origin header is "chrome-extension://[CHROME EXTENSION ID]". This means requests from Chrome extensions are subject to the same CORS rules described in this article.

Categories