How Apps framework client.request works

Have more questions? Submit a request

6 Comments

  • Amos Shacham

    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

     

    1
  • Bryan Flynn

    Hi Amos -- I know you have a ticket open on this and the issue is being investigated. Explicitly setting "cors:false" seems to keep the proxy from sending the ORIGIN header when using Chrome. This can be used as a workaround in the meantime. For further communications, please use the ticket that you're assigned. Thanks again for raising this!

    0
  • Amos Shacham

    Hi @Bryan,

     

    I do have a ticket open but I will also update here that adding "cors:false" doesn't change anything in the behaviour and the "origin" header is still being sent.

    Amos

    0
  • Bryan Flynn

    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.

    The mention in the above comment about explicitly setting cors:false not making that happen was false -- sorry for any confusion. There was testing with Firefox, which has differences from Chrome, which created some confusion (for those who are interested, this Stackoverflow post describes the differences really well).

    0
  • Amos Shacham

    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

    0
  • Bryan Flynn

    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.

    0

Please sign in to leave a comment.

Powered by Zendesk