How Apps framework client.request works

>>>>>>>

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?

>>>>

tell me if I got this right...the request from the browser to the proxy is SAME ORIGIN

<<<<

That is correct. When calling the proxy, it is always same origin, regardless of action. That's because the proxy is always called under the same domain as the account.

This is the format of the call to the proxy (also mentioned in the above article):

https://yoursubdomain.zendesk.com/proxy/to/https://api.github.com

The remote API endpoint the proxy will call is always tacked to the end of proxy endpoint.

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.

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

Hi Amos. It's browsers on their own that will create OPTIONS calls. Since the API call is coming from our backend proxy service (not a browser), there will be no OPTIONS call.

Also, the proxy just passes the ORIGIN header through if it receives it. It won't add it on its own. I think the point to clarify is that the initial call to our proxy is coming from a browser. So despite an ORIGIN header not being explicitly added in your code, the browser will add it automatically. That's not Zendesk doing it, it's the browser.

Edit: And as far as the call from the front-end browser to the back-end proxy, those are in the same domain. The browser will not generate an OPTIONS call on the same domain.

Bryan Flynn - 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 6482129967,

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

A CORS call is interesting (and can be confusing) in that it is actually the browser that determines if the final response received should be rendered. 

In other words, it is the browser that determines if the call's response should be rendered or not based on primarily these two points 1) different origin was called 2) Access-Control-* headers received in the response and their values.

With cors:false, the call is made via a backend proxy, not directly from the browser. Thus, the proxy does not care about where the call is going or what Access-Control-* headers it gets back. It just makes the call, receives the response, then passes it back to the browser. Kind of like if you were making the call from a tool such as cURL on the command line -- there is no concept of origin in that context. 

And since the call from the browser to the proxy (when setting cors:false) is *same origin*, there is no possibility of a CORS failure. So with this feature, you can make calls to other services that typically wouldn't allow a direct cross-origin call from a browser.

As a side note, if you are making API calls directly from a browser (and not through a proxy), this article might also be helpful: CORS Troubleshooting

The bottom line is that, if you have a remote server that typically doesn't allow cross-origin calls, you might be able to work around the limitation by going through a proxy. The free proxy that Zendesk Apps framework provides helps facilitate that kind of scenario.

This was moved to a ticket but to close out this conversation for others, headers that the browser passes to the proxy service are passed on to the eventual endpoint. So in this case, Chrome was passing ORIGIN to the proxy, which then passed it on.

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