עמוס שחם

>>>>>>>

And because it is always a same origin call, the browser is not looking for or expecting cross-origin Access-Control-* headers in the response.

<<<<<<<

This is where I think you're wrong, and correct me if I'm wrong, cause I'm no CORS expert. But from what I read in the specs, if it's a POST call, then even if it's to same origin, the browser *is* looking for the cors headers.

If I'm right, I guess that means that the zendesk proxy *should* return the CORS headers for same origin POST calls, as it indeed approves them.

No?

OK, so please tell me if I got this right or if I missed something - the request from the browser to the proxy is SAME ORIGIN, *but* if you use a "post" request, then, according to the specs, this now becomes a CORS request. The browser won't send the OPTIONS preflight, but it will add the ORIGIN header.

Your server will send this to the remote server, which might only support backend requests and not CORS request. So when the request will get back to the proxy and to the browser, it will not have the CORS needed headers, and the browser will block it.

Am I correct in all this?

How can we then make non-CORS POST requests? Can Zendesk ignore the ORIGIN header when cors:false is used (even though the browser do send one)? And if so - will that solve the problem?

Thanks,

Amos

@... - In addition, when the browser is detecting a post request to a different domain, it first preflight the request with an OPTIONS verb request - does that mean Zendesk proxy is doing the same?

Again, from my understanding, the purpose of the proxy (cors:false) is to get over a cors request. But if the proxy does exactly what the browser is doing (adding origin header and sending an OPTIONS request) - how is this helping in that?

I think the point is that when we're using ZAF's request option, and tell it all the details of our request, it should be sent to the proxy and from there to the our endpoint as we asked it to be - so if we asked for a POST request without an origin header, don't add one... no?

Hi @...,

I don't understand the point of the proxy if it mimics the browser request.

The whole idea of the proxy is to be able to avoid CORS checks. This is what this article is all about.

Correct me if I'm wrong, but the origin header is what makes the request a CORS request. It doesn't matter who sends it - whether it's the browser or a server. The server that receives the request thinks it comes from a browser if it has that origin header.

If Zendesk server also send this header - how can we avoid or get around CORS?

Thanks,

Amos

Thanks Bryan for clearing this out, but I think I'm not following.

Wasn't the purpose of the proxy to allow us to make server side requests? So we can avoid the CORS issue?

I guess what I'm asking is:

1. What's the point of CORS:false if it still sends the origin header?

2. How do we make non-cors, server-side requests?

Thanks,

Amos

Hi,

Thanks so much for this information.

For some reason, when I try to use the proxy service (by not specifying cors:true in the request), it doesn't work.

I can see in the network pane of the browser that indeed a request was made to the proxy service, but in my server I can see the incoming request and it does include an "origin" header.

What am I doing wrong?

Thanks,

Amos