iconclass-API - Options-Requests vs CORS

#1

Hi everyone! :wave:

For years, we have been using the Iconclass API in easydb5 and fylr to handle the relevant linking: GitHub - programmfabrik/fylr-plugin-custom-data-type-iconclass · GitHub

Our system requirement for fylr is the use of Chrome. However, a user now needs to use Firefox and discovered that—unlike Chrome—Firefox sends preflight requests (OPTIONS) when using the iconclass-API. The correct response is received, but the Access-Control-Allow-Origin: * header is missing from the OPTIONS request response, resulting in CORS errors.

It is already included in GET requests… Could you please add that header for OPTIONS requests as well?

Thanks and best regards, Tobias

#2

Thanks for the report Tobias.

This should be a small quick-fix, we will deploy it to the production service as soon as possible, and also make sure it goes into the new version under development.

#3

Any news with my issue? :slight_smile:

#4

Hello Tobias,

Hope you had a great summer too, I am back in the office starting today.

I have pushed a fix to the Iconclass website so it also responds to OPTIONS requests.
Please check if this resolves the request from your Firefox customer.

You can test this with a command like this in a Terminal window :
curl -v -X OPTIONS https://iconclass.org/api/search

Or using some online services like this HTTP tester: https://reqbin.com/pkehqnft

#5

Hey Etienne,
thanks a lot. Unfortunately the fix works fine with curl and postman. But not in real environment. Browsers automatically add an “Origin: http:foobar” to the Requestheaders. That causes a 400-Response in your Webserver. I build an example: https://reqbin.com/mylovjw5

Or try

curl -i -X OPTIONS "https://iconclass.org/api/search?q=hirsch&lang=de&size=999&page=1&sort=rank&keys=0" \
  -H "Origin: https://example.com" \
  -H "Access-Control-Request-Method: GET"

If you remove the “Origin”-Header, it works fine…