I am trying to make a simple AJAX POST request. This request when executed in POSTMAN works fine. However, when I code it in jQuery and try to make the same request, I get
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'file://' is therefore not allowed access. The response had HTTP status code 415.
Now, I have to make a POST request and hence using JSONP as type in the request won't help. I do not have access to server code to modify it. My basic understanding is that if POSTMAN can execute it, then i should be able to do it as well
the status code is self explanatory.
415 it's returned from the server when you sent an unsupported content type (e.g. an xml). double check the type of data you're passing to the post request in your code.
415 UNSUPPORTED MEDIA TYPE The origin server is refusing to service
the request because the payload is in a format not supported by this
method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
I doesn't automatically work in the browser if it works in Postman. You can still get CORS-errors.
You might also check the content type, you are getting HTTP STATUS 415 which is UNSUPPORTED MEDIA TYPE
. This might be your problem, the media type differs in the request.
I also noticed you are serving from file://, maybe you should host it so you are serving your site from localhost instead.
Ok, so the issue is you are running your page from a file directly(May be just double clicking on the file in windows) rather using an server.
So first of all access the page via server, install any server like apache, and access the page via
http://localhost/pagename
Related
I'm creating an Angular application with which I want to use the DEGIRO public API. Something is going wrong with cross-origin requests between my application and the external API.
When I run the application on localhost with ng serve my preflight requests pass the access control check perfectly. However, I run into problems when I run the application with any other origin host like [any IPv4-address]:4200 with ng serve --host [any IPv4-address]. The same problem also occurs after deploying to for example Firebase.
To communicate with the API I use the HttpClientModule with Angular as shown in the image below.
Angular HTTP POST API call
The problem I run into is described to me by the error message below.
"Access to XMLHttpRequest at 'https://trader.degiro.nl/login/secure/login' from origin
'http://192.168.178.120:4200' has been blocked by CORS policy: Response to preflight request
doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the
requested resource."
The main reason this error confuses me is because it doesn't happen from localhost. In the two images below the differences between the preflight request headers(localhost:4200 & 192.168.178.52:4200) are shown. Please note how the only differences are the origin and referer headers. The deployed application on Firebase is also similar like this.
Http request header (localhost)
Http request header (IPv4-address)
I've tried skipping the preflight request by adding a 'content-type': 'text/plain' header, but even the now simple request wouldn't be accepted by the CORS policy.
I have also read several somewhat similar issue's, but none of them matched my case perfectly and neither did their solutions. Next to these I have also read up a bit on CORS. I found this article very informative and helpful. https://www.html5rocks.com/en/tutorials/cors/
I can't think of any more context. I hope this post is clear and you're able to help. Thanks in any case!
Did you request a session with VWD service?
As I can see first you need to make POST request to:
https://degiro.quotecast.vwdservices.com/CORS/request_session?version=1.0.20170315&userToken=YOUR_TOKEN
And provide header:Origin: 'https://trader.degiro.nl'
and provide body: JSON.stringify({referrer: 'https://trader.degiro.nl'})
After you get the session you use that to for example: get latest bid/ask prices for a VWD issue ID
Check this package out, take look at how they managed to get it working.
Cheers :)
I called https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/<id>/<LOBType>/contentVersions/<content_version_id>/files, and received the azureStorageUri from it, but when I try to upload something into it (splitting the file into chunks), I always get 403 CORS not enabled.
I add $comp=block&blockid=<base64 block id> to the received uri.
My header is:
'x-ms-block-type': 'BlockBlob'
The exact error I receive is:
<Error>
<Code>CorsPreflightFailure</Code>
<Message>CORS not enabled or no matching rule found for this request.
RequestId:ce3ea3a7-f01e-0068-24b5-2c0795000000
Time:2018-08-05T12:10:00.6698414Z</Message>
<MessageDetails>No CORS rules matches this request</MessageDetails>
</Error>
Seeing as I always get the CORS issue, I tried enabling it by following this page, but, when making the request, again I receive the same CORS error.
I'm running it in my browser, if it's any help.
I'm kinda stuck and don't know how to proceed now. I'd be happy for any help. Thanks! :)
Edit: When I make the same request via Postman, it works just fine.
I'm kinda stuck and don't know how to proceed now
If you want to send a cross-origin request successfully, the request must match the CORS configuration including the request origin, headers & response headers. By default, CORS is disabled for each service. You could add the CORS setting for storage service. We could get more information about CORS from this article.
Note: CORS is not supported for Premium Storage accounts.
We could set it from Azure portal.
You can also use the wildcard character '*' to allow all origin domains to make requests via CORS.
We have been encountering inconsistent client errors with a single-page JavaScript application making fetch requests. Of note, they are all same-origin requests.
let request = new Request(url, options);
...
window.fetch(request)
.then(response => response.json())
.then(data => ...)
.catch(error => ...)
Around 5% of the promises are rejecting with the following error despite the server and the browser receiving a 200 OK response:
TypeError: Failed to fetch
I'm stumped... All of my searches lead to discussions about CORS errors. That doesn't seem to apply given these are all same-origin requests. What is causing the fetch to throw the TypeError?
I can confirm using the Network tab in Chrome DevTools that the fetch request completes with a 200 OK response and valid JSON. I can also confirm that the URLs are same-origin. I can also confirm that there are no CORS pre-flight requests. I have reproduced this issue on Chrome 66 and Safari 11.1. However, we've received a stream of error reports from a mix of Chrome and Safari versions, both desktop and mobile.
EDIT:
This does not appear to be a duplicate of the linked question as we are not sending CORS requests, not setting mode: "no-cors", and not setting the Access-Control-Allow-Origin header.
Additionally, I re-ran tests with the mode: 'same-origin' option set explicitly. The requests are (still) successful; however, we (still) receive the intermittent TypeError.
I know that this is an old issue, but after searching the entire evening I want to share my findings so you can spend your time better.
My web app also worked well for most users but from time to time visitors received the error mentioned in the question. I'm not using any complicated infrastructure (reverse proxy etc.) setup nor do I communicate with services on a different domain/protocol/port. I'm just sending a POST request to a PHP-File on the same server where the React app is served from.
The short answer: My problem was that I've sent the request to the backend by using an absolute URL, like https://my-fancy-domain.com/funky_service.php. After changing this to a relative path like /funky-service.php the issue was gone.
My explanation: Most users come to the site without www in the URL, but some users actually do type this part in their address bars (www.my-fancy...). It turned out that the www is part of the origin, so when these users submit the form and send post requests to https://my-fancy... it's technically another origin. This is why the browser expects CORS headers and sometimes even sends an OPTIONS preflight request. When you use a relative path in your JavaScript-Code the post request will also include the www-part (uses the origin from the address bar) -> same-origin -> no CORS hassle. As it only affects visitors that come with the www to your site it also explains the fact that it worked for most users even with the absolute URL.
Also important to know: The request fails in the browser/ JavaScript-Code but is actually sent to the backend (very ugly!).
Let me know if you need more information. Actually, it is very simple but hard to explain (and to find)
The issue could be with the response you are receiving from back-end. If it was working fine on the server then the problem could be with the response headers. Check the Access-Control-Allow-Origin (ACAO) in the response headers. Usually react's fetch API will throw fail to fetch even after receiving response when the response headers' ACAO and the origin of request won't match.
Ref: Getting "TypeError: failed to fetch" when the request hasn't actually failed
In Internet Explorer, the requested url is being blocked due to mime type mismatch. The scenario is that request is being sent from the client to the destination server through proxy server. Suppose we have A(Client), B(Proxy Server), C(Destination Server). The request goes from A(client) to B(Proxy server) and from B(Proxy server) to C(Destination server). Similarly the response also comes from C(Destination Server) to B(proxy server) and from B(proxy server) to A(client) from where the request was initiated. Now the problem is that the response Content-type is "application/liquid" but the client fires the request using the "script src=proxyserver/test" , so the excepted Content-Type for response becomes "text/javascript". It is not allowed to change the Content-type of response from "application/liquid" of the destination server. The whole scenario works perfectly in all the other browser and the response is easily accessible. However in IE as we are getting the error as "request blocked due to mime type mismatch " . So can anyone provide the solution that how could we make it work ?
Below is the screenshot of the error.
TL;DR - you will need to change the mime types.
This problem appears when the requests expected type is different from the response-content type (as indicated by the headers). The correct solution would be to make response and request headers compatible with each other. That means, the call you make "through a script tag" should be changed to have the same accept header as the response's content-type header.
Also, take a look at the documentation:
nosniff Blocks a request if the requested type is "style" and the MIME
type is not "text/css", or "script" and the MIME type is not a
JavaScript MIME type.
See here.
I see that this URL: https://nirma.myshopify.com/apps/GeoShippingBar/geoShippingBarProxy has this content-type: Content-Type:text/html; charset=utf-8 which is not javascript-mime-type.
Try this:
response.addHeader("accept","text/javascript");
set in the response of script tag from where it is called.
You need to create a script , an external script which will give the call to the desired code using a ajax call or xmlhttprequest , where you will need to set the accept header so the desired mime type. So from the client it will call that external script using the script tag which will get executed through the proxy server and which will further give the call to the actual data and recieve its response and send back to client. But as it will call the script, by default header would return as text/javascript and the error will get resolved.
Basically you cannot do this. App Proxys are meant for creating pages not script files.
A possible strategy that will get you where you want to go is as follows:
The dynamic from liquid parts can be put into a snippet.
<script type="text/javascrpt">
geoShippingConfig = {
somevalue: '{{ shop.X }}',
etc
};
</script>
And you inject that into the main layout when your app is installed. Various apps do this sort of thing. You have to warn the customer that you are going to to that but it's fairly benign. You also need a refresh button or some way to re-inject the snippet and the include when the theme changes.
Then your app installs a Script Tag with your code instead of calling an app proxy. Script tags include the shop in the url so you can do any app specific config to the returned script file. Your script tag script uses geoShippingConfig on load.
Medium has an RSS feed available at https://medium.com/feed/[#username]. I'm trying to fetch all my blog posts using an XMLHTTPRequest. When I test on local, I run into CORs errors. When I turn on CORs Chrome extension, I get a 401 error. Any ideas? Has anyone succeeded in calling Medium RSS?
To get https://medium.com/feed/[#username] content using XHR, you can make the XHR request through a proxy of some kind. For example, trying giving your current XHR code this URL:
https://cors-anywhere.herokuapp.com/https://medium.com/feed/#sideshowbarker
That’ll cause the request to go to https://cors-anywhere.herokuapp.com, a open/public CORS proxy which then sends the request on to https://medium.com/feed/#sideshowbarker.
And when that proxy gets the response, it takes it and adds the Access-Control-Allow-Origin response header to it and then passes that back to your requesting frontend code as the response.
That response with the Access-Control-Allow-Origin response header is what the browser sees, so the error message the browser is showing you now goes away, and the browser allows your frontend JavaScript code to access the response.
Or use the code from https://github.com/Rob--W/cors-anywhere/ or such to set up your own proxy.
The reason you need a proxy is, responses from https://medium.com/feed/[#username] don’t include the Access-Control-Allow-Origin response header, so your browser will refuse to let your frontend JavaScript code access those responses cross-origin.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS has more details.
This is a bug.
Bug has opened. (Dan Abramov approved)