Chrome version: 57.0.2987
Actually, in older Chrome version I also have this problem.
I added Authorization on Request Header with my access token,
fetch('https://example.com/endpoint', {
method: 'GET',
headers: {
'Authorization': 'Bearer ' + accesstoken
}
})
I always get Access-Control-Allow-Headers:authorization on Response Header in Chrome
Besides, My fetch is always Request Method:OPTIONS (not display GET), then Status Code is 200 OK in Chrome
But if I run the same fetch code in Firefox (ver 52.0.1 ), everything works great. I can add Authorization on Request Header correctly. It won't display Access-Control-Allow-Headers:authorization on Response Header in Firefox. It will display Authorization: Bearer accesstoken on Request header.
The server side already processed CORS for my request header..
This is a Chrome bug or my code fault? How should I do to make Authorization on Request Header correctly in Chrome?
Below image is the detail Network in Chrome dev tool:
Below image is the detail Network in Firefox dev tool:
As #stackdave said, browser send OPTIONS request before GET request when cross-domain ajax. Then browser will wait server response. My situation that the server didn't response, so browser just stop OPTIONS status. Server need to handle this issue, it's still CORS issue, not fetch api bug or issue.
browser will send before a OPTIONS request, without the authorisation token, and then will send the real request
http://www.w3.org/TR/cors/ See http://metajack.im/2010/01/19/crossdomain-ajax-for-xmpp-http-binding-made-easy/ for a bit more info
Related
It's a little difficult for me to search for a response to my question because so many people are asking a different question that uses most of the same words.
I'm creating a site on Wix and using their Backend Code platform to create an HTTP endpoint. The HTTP endpoint sends an email to me using nodemailer, a feature which is not available in the browser.
While testing I set the Endpoint to be wide open using these headers.
{
"Accept": 'application/json',
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods": "POST, GET, OPTIONS",
"Access-Control-Max-Age": "86400",
"Access-Control-Allow-Headers": "Content-Type"
}
And when I send the fetch request to the HTTP Endpoint on localhost, everything works as expected.
Now, Wix requires custom HTML code to be embedded in an iframe. Developers don't have direct access to the code on their site. When I embed the code with the fetch request into an iframe and click the button to send the fetch request I get blocked by CORs.
I can see, in the Chrome Developer Console that Chrome is sending the fetch request, but along with the first Options request Chrome isn't getting the correct headers from the Endpoint. The request is subsequently blocked.
Is there any reason why being embedded in an iframe would cause this code not to work?
If this is impossible, which I fear, what other way is there to send an email from an iframe?
Anyone ever had an issue when embeding a docusign signing ceremony in an iFrame?
I'm trying to test docusign embed signing by using an iFrame. But the browsers (tested on Chrome, Firefox) are refusing to render the url.
I get the embed url (which looks like https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX) from DocuSign and then sets this url to iFrame source on my website. But it just shows a blank page nothing comes up (instead of embeding in an iframe if I just paste the url in the url bar it renders fine). If I check the console logs in Google Chrome (on win10) I see an error
Refused to display 'https://account-d.docusign.com/recipient/auth?ui_locales=en' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
<iframe src='https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX' height='900' width='900'>
</iframe>
If I observe the network tab the following redirects are happening:
Request URL: https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://account-d.docusign.com/managed_token/v1/redeem/?slt=XXX
Request URL: https://account-d.docusign.com/managed_token/v1/redeem/?slt=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://demo.docusign.net/Signing/StartInSession.aspx?code=XXX
X-Frame-Options: SAMEORIGIN
Request URL: https://demo.docusign.net/Signing/StartInSession.aspx?code=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://demo.docusign.net/Signing/ActivateSecurityChecks.aspx?insession=1&ti=XXX
Request URL: https://demo.docusign.net/Signing/ActivateSecurityChecks.aspx?insession=1&ti=XXX
Request Method: GET
Status Code: 200 OK
Response Headers
Set-Cookie: BIGipDocuSign_Demo_Signing=XXX
X-DocuSign-Node: XXX
Request URL: https://account-d.docusign.com/recipient/auth?ui_locales=en
Request Method: GET
Status Code: 200 OK
Response Headers
X-Frame-Options: SAMEORIGIN
X-DocuSign-TraceToken: XXX
X-DocuSign-Node: XXX
Note: I followed this sample from docusign's official examples.
EDIT
RecipientViewRequest:
{
"AssertionId":"logging in event id",
"AuthenticationInstant":"1\/29\/2020 11:09:26 AM",
"AuthenticationMethod":"password",
"ClientUserId":"logged in user id",
"Email":"my-email#mydomain.com",
"ReturnUrl":"https:\/\/subdomain.mydomain.com\/recieve",
"UserName":"signerFirst lastName",
"XFrameOptions":"allow_from",
"XFrameOptionsAllowFromUrl":"https:\/\/subdomain.mydomain.com"
}
EDIT 2
If I recall, the embeding method had worked for me in the past while testing.
This behavior of refusing to render in iFrame has started fairly recently. Maybe they have changed on their end during last month.
In general, iframes are discouraged due to compatibility and difficulty in troubleshooting. The recommendation is to instead redirect the user to the URL and then catch the returnUrl redirect upon completing.
That said, there are two relevant parameters in the Envelopes::CreateRecipientView call
"xFrameOptions": "allow_from",
"xFrameOptionsAllowFromUrl": "https://example.com"
where the xFrameOptions parameter should be "allow_from" to enable this functionality, and AllowFromUrl should be the domain of your site.
I want to use HERE maps autocomplete in my project.
But when a i send request like the one in documentation
this.axios.get('http://autocomplete.geocoder.api.here.com/6.2/suggest.json
?app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
&query=Pariser+1+Berl
&beginHighlight=<b>
&endHighlight=</b>'
)
.then(response => {
console.log(response)
})
.catch(error => {
console.log(error)
})
i get an error
OPTIONS http://autocomplete.geocoder.api.here.com/6.2/suggest.json?{...} 405
Access to XMLHttpRequest at 'http://autocomplete.geocoder.api.here.com/6.2/suggest.json?{...}' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
In Chrome developer console in network panel i check this
Provisional headers are shown
Access-Control-Request-Headers: x-auth-token, content-type
Access-Control-Request-Method: GET
I set content-type in request headers to application/json and Provisional headers changed
to Access-Control-Request-Headers: x-auth-token
Access-Control-Request-Method: GET
So if i understand right, i should set x-auth-token header. But where can i take this token?
Or may be this problem has another reason?
There's nothing about such problems in documentaion.
The problem was simple and a bit stupid.
When user authenticated in my app I added default header to axios
axios.defaults.headers.common['X-Auth-Token'] = token
so this header was sended to all requests.
But HERE-map API doesn't want this header in requests and this was the cause of the problem.
The solution was to remove this header from requests to HERE-map API.
For those who have defined by default the header :
'Content-Type': 'application/json'
You must deactivate it, there should not be any HttpHeaders on the call request to Here API services.
temporary install Allow-Control-Allow-Origin google chrome plugin .. installed then you can show top right side click on that and switch the button then refresh then again call your api and get the response.
I'm testing an app locally and am making an authorization request to http://localhost:3000/api/auth/login. A set-cookie header is returned in the response with a JWT auth token. The JWT looks like:
JWT-TOKEN=[really long alphanumeric string];Version=1;Comment=;Domain=;Path=/;Max-Age=3600;;HttpOnly
Afterwards, I'm making another request to http://localhost:3000/api/other/resource and am getting an unauthorized error as it's expecting a cookie with the JWT token in the request.
The Cookie is being set in Firefox, Safari and Chrome but not Edge. Nothing in the Edge dev tools console that anything went wrong. Any ideas why the cookie is not being set in Edge?
I found an answer that worked in my case.
We were using fetch on the client. In some older browsers, the native fetch implementation would default to credentials: "omit", whereas newer browsers default to credentials: "same-origin".
As such, adding this option seemed to allow Edge to receive cookies in fetch requests, such as
fetch('/users', {
credentials: 'same-origin'
})
https://github.com/github/fetch#sending-cookies for reference. Despite the name of the heading, "omit" will disable both sending AND receiving cookies.
I need to make an HTTP GET request with custom request headers in-browser and process the result as it streams in. The Fetch API is ideal for this:
fetch('https://example.com/resource', {
method: 'GET',
headers: {
'X-Brad-Test': 'true'
},
cache: 'no-store',
mode: 'cors'
}).then((res) => {
const reader = res.body.getReader();
// etc.
});
This works quite well. Since there are custom headers, the browser pre-flights the request with an OPTIONS request to /resource. I have configured my server to respond with a 204 No Content and the following headers:
Access-Control-Allow-Headers: X-Requested-With, Range, If-Range, X-Brad-Test
Access-Control-Allow-Origin: *
The browser is happy with this, then makes a GET request, the server returns a 200 OK with the data, and the browser allows me to access the response headers and body.
The problem comes in when there is a redirect. The OPTIONS request succeeds with the 204 No Content and the same headers as before. The browser makes the correct GET request, and on the server I send a 302 with a Location: header. Chrome throws the following error:
Fetch API cannot load https://example.com/resource. Redirect from 'https://example.com/resource' to 'http://some-other-origin/resource' has been blocked by CORS policy: Request requires preflight, which is disallowed to follow cross-origin redirect.
This was unexpected, and seems nonsensical to me. I expected the browser to follow the redirect, and do another pre-flight request for this new location, but it didn't do that.
Stranger still is that I can sort of hack around this client-side. I can make an HTTP request without my custom header, figure out where I ended up after redirects by looking at the Response object, then make a second request at the new target with my custom headers. This doesn't work in all cases of course, and I'd rather not rely on this hack. I'd rather find a proper way.
Two Questions:
What is the proper way to allow the client to follow redirects? Is there some sort of Access-Control-* header I can use?
Why does this restriction exist? What security issue is prevented by not following and running pre-flight on the followed URL?
Supporting redirects to requests that require a preflight is very recent change to Fetch (which defines CORS).
https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2
I believe some implementations have started adjusting their implementations, but this will take some time to reach everyone.