CORS-Error only for "Omeka-S-module-ApiInfo" not for the built-in API

Hey guys,

I have a little problem with the module “Omeka-S-module-ApiInfo” from Daniel-KM. In principle, it does exactly what I need. We are using Omeka-S as a headless CMS with the rest api. Unfortunately, I need the total number of items of my executed search for pagination. Omeka provides this in the header. But the CORS policy forbids custom headers. I am not allowed to read them. That’s why I came to the above mentioned module. Theoretically it returns the correct results (tested with Postman/–disable-web-security) but I get a CORS-Policy error again.

The Build-In API was allowed via .htaccess file and “Access-Control-Allow-Origin”. This also works wonderfully. But somehow this does not include the module. I have already tried to put a .htaccess in the module folder, but without success.

Does anyone know the problem and can push me in the right direction?

The problem is just that you can’t read a custom header?

Access-Control-Allow-Origin only lets you access things you otherwise couldn’t, it doesn’t affect what headers you’re allowed to see. You’d need to use Access-Control-Expose-Headers for that.

“Access-Control-Expose-Headers” is a very good tip! Thanks a lot :slight_smile: But I would prefer even more now if the plugin would work. Do you have an idea why I may request the built-in API, but the info-api of the module throws cors-error? The request comes from exactly the same server, even from the same page. Somehow the plugin doesn’t seem to have been permitted with it.

I don’t know how the ApiInfo module works. If it’s at a different URL than the built-in API, perhaps you just need to adjust your .htaccess Access-Control-Allow-Origin rule to apply to the other URL.

I am not sure. Whether it’s a different endpoint or just a different resource. Excerpt from the doc:
“Data are available in /api/infos/{name} via a standard request.”

But I don’t understand your tip. I set the header on the server that gets the request. Not in the one that sends the request.

My suggestion is that the .htaccess rule you’re using isn’t setting the header on the “/api/infos” responses. Have you checked to see if the header is there?

Super strange! I looked at your question with Postman in the header. Indeed it is sent along! Then I tried it in Firefox. There it works wonderfully. But the Chrome based browsers (also Edge / Brave) throw this error in the console:

“Access to fetch at ‘xxx’ from origin ‘xxx’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.”

Now I understand even less^^

EDIT:
Okay, it will not be the same header that is sent when you request with postman or fetch(). In fact, in the network tab, there is no header in the response. Unlike the fetch requests that work normally, here is also a different status code.

Successful Request
HTTP/1.1 200 OK
Date: Wed, 24 Mar 2021 18:32:44 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000
Link: ; rel=“first”, ; rel=“next”, ; rel=“last”
Omeka-S-Total-Results: 5066
Omeka-S-Version: 3.0.1
Vary: Accept-Encoding
Content-Encoding: gzip
Access-Control-Allow-Origin: xxx
Content-Length: 6491
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8

Failed Request
HTTP/1.1 307 Temporary Redirect
Date: Wed, 24 Mar 2021 18:32:44 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000
Location: xxx
Content-Length: 345
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Maybe it is because of the internal forwarding?

The solution was a simple little /.
This one was too much in the request. Firefox doesn’t seem to mind this. But Chrome didn’t want that.

WRONG
“infos/?per_page”

CORRECT
“infos?per_page”

Note about the total number of results: since Omeka v3, the total number of items of any query is available in the headers of the response, so you don’t need a specific call to the module to get it.
The urls is /api/infos/xxx , and there are many infos available that are used by many javascript themes.

Oh yes, thanks, at first I thought I wasn’t allowed to access the header because of CORS. But thanks to you, the header and the module now work. Thanks a lot!