Making cross-origin, browser-side API requests Follow

Comments

2 comments

  • Avatar
    Andrew Sharpe

    Great writeup, thanks!

    There is one issue with using Zendesk in this way, which is the lack of CORS headers for anything other than a 200 response.

    This article implies that the lack of CORS headers is used as access control however that's built into Zendesk proper.

    If the user making the request does not have permissions to use the API endpoint (as specified by the "Allowed for" sections in the API docs), the "Access-Control-Allow-Origin" header is not included in the response. The missing CORS header prevents the user from accessing the resource in the Zendesk domain.

    The lack of CORS headers for unauthorised requests means that the client application cannot handle issues gracefully.  Zendesk is actually returning a 401, which indicates correctly the reason why the user cannot access the resource.  The same applies if the token is invalid/expired, and the app cannot make an intelligent decision without the CORS headers in the response.

    Another example is the "429 Too Many Requests" response that Zendesk can return.  Because this response doesn't have CORS headers the application does not get a chance to identify this issue and respond accordingly.

    Could Zendesk please return the CORS headers for requests that fail too?

  • Avatar
    Charles Nadeau (Edited )

    Thanks very much for the feedback, Andrew. I updated the wording in the article to make this clearer. 

    I ran some quick tests and I'm able to confirm that the headers are returned on 200, 201, 204, and 404 responses. Not sure if there are any others.

    I brought this issue to the attention of the API product team.

Please sign in to leave a comment.

Powered by Zendesk