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?
Related
Sorry for my English)
I have an account on https://naurok.com.ua (login: kuz.code.official#gmail.com, password: 2455s1). I log in, then follow the link /test/test-po-filosofii-541029/flashcard.
After I followed the link, it loads the cards through a request /api/test/documents/541029/flashcard.
I need to send it successfully:
I test request by Postman api/test/documents/541029/flashcard. Request sends with captured Cookies, but it says I need to log in ("Необходимо авторизоваться").
Why query work on website but doesn`t in Postman?
you need add the most important thing which is to add the cookie PHPSESSID you can find it on your browser when inspecting the request on network tab
like this
click on "cookies" on postman
to have it like this
or click on "code" on postman
I noticed also you need referer header otherwise it won't work
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
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.
I have a web server which contains an API to upload files to Amazon's S3 storage. Since I do not want to waste resources on streaming the files through my server, when an upload request comes in, I generate a pre-signed URL for the client and then redirect that client to this URL using HTTP 307 - Temporary redirect.
In practice, the flow looks like this:
Client issues a PUT request to my server, requesting a file upload
My server inspects the request and generates a pre-signed URL for S3
My server responds to client with 307 redirection to the pre-signed URL
Client repeats the PUT request to the pre-signed URL
Upload commences
The challenge
My server uses the Authorization header for... well, authorisation. Incidentally, Amazon also accepts this header for authorisation, although the values expected by both parties are completely different.
The problem is, that since my upload API requires this header to be present during file upload request, when my server issues the 307 redirect back to the client, the client takes all the headers in the original request and sends them along to the pre-signed S3 URL, which causes the request to be rejected by Amazon due to authorisation error.
The question
Can I somehow instruct the client (via HTTP response header) to not include the Authorization header when following the redirection?
Current solution
Right now we "fixed" this by returning the pre-signed URL to the client in the response body. The client then manually issues a new PUT request to that URL without the Authorization header. This works fine. I would like to know if there is a way to achieve this behaviour without this extra manual work.
What is the client? In the above statements, when I mention the "client", right now it could be either a modern web browser or a native iOS or Android app. On iOS, we use Alamofire for HTTP communication. I am unsure of what library or components are used on Android.
Note: I have seen this question and its answers, but it does not contain the answers I seek.
I use the next link in order to send chunking files with plupload.
I change the url parameter in order to send the request to my localhost:
url: "./upload.cfm", was changes to url: "localhost/upload"
As I see, the request is sent, but with request methods: OPTIONS.
Why it happens and how I can change it to POST?
Since you are now making a cross-origin HTTP request, you are triggering a preflight request in which the browser asks the destination server if your website is allowed to ask browsers to make POST requests to the destination server.
Either configure the destination server to respond to the OPTIONS request with a response granting permissions (after getting that response the browser will make the POST request), or continue to make requests with XHR only to the same origin.