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 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.
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!
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.