CORS issue between UI and couchDB - javascript

I have CORS issue between UI and couchdb.
But in couchdb CORS is enabled, and UI has res.header("Access-Control-Allow-Origin", "*"); header.
But I still have an error
XMLHttpRequest cannot load http://localhost:5984/cp_display_template/.
A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin'
header when the credentials flag is true. Origin 'http://localhost' is
therefore not allowed access. The credentials mode of an
XMLHttpRequest is controlled by the withCredentials attribute.
Someone has an idea why?

Not 100% sure about this but try instead using * use localhost:5984 in Access-Control-Allow-Origin header. because for some security reason you can allow all requests. need to indicate specific domain

Related

Confusing CORS errors and how to use a CORS proxy

So I've been working on an in browser program that uses fetch to get some data from an api, and because the api only returns data in chunks I need to send a total of 70-100 requests, one after another at about 5/second. However about 50% of the time I get a CORS error:
Access to fetch at 'https://api.hypixel.net/skyblock/auctions?page=49&key=7a5825e3-2d47-4ff4-894f-7fd2a6c9ca17' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Strangely enough, when it does happen, the error seems to occur at a random point through the 80 or so requests. I understand the concept of a CORS proxy but I cannot figure out how to use it in practice. Could someone explain how to use any of the CORS proxy websites to avoid this error.
Did you add this to your package.json:
"proxy": {
"*":{ "target" : "http://myurl"}
}
And set headers like:
axios.defaults.headers.post['Content-Type'] ='application/json;charset=utf-8';
axios.defaults.headers.post['Access-Control-Allow-Origin'] = '*';

How to fix blocked redirect due to CORS issues?

Here is my setup:
Running a local angular application on port 4200
Running an API using Deno on port 4300.
I have a use case where a client call at some api endpoint http://localhost:4300/foo, needs to redirect the user to another portion of the front end, say http://localhost:4200/bar#baz.
Currently this fails with the following error:
Access to XMLHttpRequest at 'http://localhost:4200/bar#baz' (redirected from 'http://localhost:4300/foo') from origin 'http://localhost:4200' has been blocked by CORS policy: Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.
I have tried disabling/allowing cors on the API:
ctx.response.headers.set('Acces-Control-Allow-Origin','*');
ctx.response.headers.set('Acces-Control-Allow-Headers','*');
ctx.response.headers.set('Acces-Control-Allow-Methods','*');
ctx.response.headers.set('Access-Control-Allow-Credentials','true');
But this does not work.
Any ideas on how to fix this? Without setting up a proxy or installing a browser plugin.
Thanks!
See MDN:
The value "*" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "*" without special semantics. Note that the Authorization header can't be wildcarded and always needs to be listed explicitly.
You are making a request with credentials therefore you can't use * as a wildcard and have to be explicit about which headers you are using.

CORS error caused due to a web API(access-control-allow-origin)

I have been trying to use a web API in javascript but I repeatedly keep getting this error:
Access to fetch at
'https://eodhistoricaldata.com/api/fundamentals/AAPL.US?api_token={token}'
from origin 'http://127.0.0.1:5500' has been blocked by CORS policy:
The 'Access-Control-Allow-Origin' header has a value
'https://eodhistoricaldata.com/*' that is not equal to the supplied
origin. Have the server send the header with a valid value, or, if an
opaque response serves your needs, set the request's mode to 'no-cors'
to fetch the resource with CORS disabled.
How should I resolve this? I installed a plugin to set the desirable header but others can't install the plugin to view data.
Perhaps this is what you meant, but it's the HTTP response from your API at 'https://eodhistoricaldata.com/' that must include the Access-Control-Allow-Origin header in its HTTP responses.
If the value of that header is 'https://eodhistoricaldata.com/*', your web browser will trigger a CORS error if you call that API from code hosted in any domain other than 'https://eodhistoricaldata.com'. To fix this, you need to change the value your API returns for this header to the domain you want to allow to call your API.
Returning the value * for the Access-Control-Allow-Origin header will allow applications from any domain to call your API without a CORS error.

javascript: fetch blocked by CORS policy because of wildcard

I am trying to use the following api endpoint using fetch:
https://api.guerrillamail.com/ajax.php?f=check_email&ip=${ip}&agent=${agent}
(outdated documentation)
When I set credentials: 'include' I get the following error:
Access to fetch at 'https://api.guerrillamail.com/ajax.php?...' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
I have to set the flag in order to submit a cookie for authentication.
After googling this problem for 1++ hour, my understanding is the following:
CORS has to be server side allowed to be able to make "none simple" request to an other domain e.g. localhost => guerrillamail.com to prevent abuse, a variable Access-Control-Allow-Origin has to be set to the domains that should be allowed to send requests. A valid option is "*", which means that ALL origins are ok.
For some reason it is not ok though in combination with the credentials: 'include flag.
Do you have any ideas why this wouldnt be allowed?
Do you know what I have to do, in order to to do the request?
And is my understanding about this correct?
The documentation you're referencing no longer applies. In that old documentation, the API was made available over HTTP rather than HTTPS. CORS doesn't apply to HTTP and wouldn't have been a problem.
In the latest documention, that API is provided over HTTPS. To deal with the CORS requirement, they also removed the need for cookies, changing it to subscr_token and sid_token parameters sent as part of the request:
version 1.5, 30th May 2011
- Removed the requirement for cookies, added subscr_token and sid_token parameters

SEC7118: XMLHttpRequest CORS - IE Console message

I am using CORS POST request with everything taken care as given #http://www.html5rocks.com/en/tutorials/cors/
Server sets Response header to:
'Access-Control-Allow-Origin':'*' and I can see this header value in IE developer tool.
But on IE10 browser I see console message as "SEC7118: XMLHttpRequest for http:// required Cross Origin Resource Sharing (CORS).
When I check on Microsoft site it has below given explanation.
http://msdn.microsoft.com/en-us/ie/dn423949(v=vs.94).aspx
SEC7118
Description:
"XMLHttpRequest for [URL] required Cross Origin Resource Sharing (CORS). "
An XMLHttpRequest was made to a domain that was different than your page's domain. This requires the server to return an "Access-Control-Allow-Origin" header in its response headers, but one was not returned.
Suggested Fix:
The server must support CORS requests and return an appropriate "Access-Control-Allow-Origin" header with the resource. See CORS for XHR in IE10 for more info about CORS in response headers.
Questions:
I want to know if this console message is an ERROR ??
Will this cause any failures ??
Why do I get this message even after setting response header 'Access-Control-Allow-Origin' value to '*'??
Does 'Access-Control-Allow-Origin' value has to be origin name for
IE10 to work? I know * is not a very good option, But does IE
requires exact origin name ??
I kept URL's and cookie details hidden from these images.
From MSDN:
Security error codes are in the form SEC7xxx [In IE]
Pertaining to SEC7118:
An XMLHttpRequest was made to a domain that was different than your page's domain. This requires the server to return an "Access-Control-Allow-Origin" header in its response headers, but one was not returned.
Note This error code was removed in IE11 on Windows 10. It remains in IE11 for Windows 8.1 and Windows 7.
So it is technically viewed as an error from IE's perspective, but certainly isn't one (hence why it is going away). Access-Control-Allow-Origin is set on a resource, but isn't necessarily sent back with the request. If a specified resource DOESN'T have Access-Control-Allow-Origin:* (or a domain), the resource would not be accessible and the server would likely return a 503 or 404 and you would see a true error message in the console similar to the below:
XMLHttpRequest cannot load http://example.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://blog.example.com' is therefore not allowed access.
I encountered SEC7118 when CORS was set up correctly. I verified that the requests were completing with status 200 using the network debugger. So, you can disregard this message if your application is otherwise functioning properly.
I have seen this error in IE11:
SEC7118: XMLHttpRequest for http:// required Cross Origin Resource Sharing (CORS)
Adding the following to my .htaccess fixed it:
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
<FilesMatch "\.(cur|gif|ico|jpe?g|png|svgz?|webp)$">
SetEnvIf Origin ":" IS_CORS
Header set Access-Control-Allow-Origin "*" env=IS_CORS
</FilesMatch>
</IfModule>
</IfModule>
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image
I had this same issue. It has to do with Internet Explorer's handing of third party cookies. You can fix this issue by going into Tools>Internet Options then selecting the Privacy tab. If you change the setting to "Accept All Cookies" you will no longer see that message.
The safer way to do this would be to click on the "Sites" button and allow cookies from your site's url.

Categories

Resources