Hi
I’ve been using a couple of endpoints successfully (/search, and /company) but I’m struggling with advanced-search. I’m getting a 403 which my browser is reporting as a CORS error. I can get the exact same URL to work in the Insomnia REST client, and I’ve checked my authorization header is being sent from my application. Any suggstions?
I think there may be an issue with the advanced search / CORS: see e.g.
Search the forum - there may be some more on this.
Good luck.
Thanks for replying. The weird thing is, it works from Insomnia (similar to Postman). So the API is working … but there must be some quirk that doesn’t happen in Insomnia, but does happen in my JS code. FWIW, I just literally flipped the code to a different API call (/search?q=…) and it worked fine. So I think my headers are OK
A further update…
I have concluded that the API for advanced search is not returning the correct response headers.
REST clients like Insomnia and Postman are immune to this as they don’t enforce CORS. The API is returning the right payload in the response, hence it all looks OK in REST clients. But browsers enforce CORS and so they refuse to accept the response.
I believe at least one header is missing - Access-Control-Allow-Origin. There could be others.
Note - this is just my best guess; I could be wrong
Interesting. All the URIs do work when called from non-javascript environments (which is how we use the system). I’ve just seen various posts on the forum specifically related to the advanced search endpoint and CORS issues. That endpoint was added much later than the others and has some differences so it’s entirely possible it has its own “features”.
If it’s exactly the same URL you’re calling in Insomnia and your API I wonder if the environment is different in those two cases e.g. is the effective domain / IP different (Companies House check this I think) and / do - or how do - the http headers differ?
Yes - I think this is what was reported in the other posts (I think in the ones I linked but I have definitely seen that on here).
The origin IP address is identical in both cases.
Insomnia reports the following response headers for the request that can’t be handled by browsers:
< HTTP/2 200
< date: Mon, 29 May 2023 08:55:54 GMT
< content-type: application/json
< access-control-allow-credentials: true
< access-control-allow-headers: X-RateLimit-Query, origin, content-type, content-length, user-agent, host, accept, authorization
< access-control-expose-headers: X-RateLimit-Window, X-RateLimit-Limit, X-RateLimit-Remain, X-RateLimit-Reset, Location, www-authenticate, cache-control, pragma, content-type, expires, last-modified
< access-control-max-age: 3600
< x-ratelimit-limit: 600
< x-ratelimit-remain: 598
< x-ratelimit-reset: 1685350720
< x-ratelimit-window: 5m
< server: CompaniesHouse
I note that access-control-allow-origin is missing, but then again, it’s also missing in Insomnia for other queries that work in a browser - so I don’t think we can read too much into that
But for those (working) queries, I can see access-control-allow-origin in the browser response headers, and it is set to my origin domain (because I have enabled that origin in my API definition registered against my application).
Anyway … I have to knock it on the head for today; hopefully someone at the CH team will see this and respond soon
Final note from me (for now!) on this, for the benefit of anyone else trying to use Advanced Search:
If you are calling it directly from JS in a browser container I think you’ll need to work around this problem by adopting a better architecture and delegating the call to a back-end service (or some other kind of proxy). My approach was always just a prototype / experiment, but it’s not a good template for production because the browser/JS exposes code and run-time data (just go into developer tools in the browser and bingo!). In this way a bad actor could easily see the API Key in use and effectively steal the credentials. Better to protect this with a server side wrapper around the calls to companies house, and this will (I expect) avoid the CORS issue. I’ll post again when I can confirm this.
And just to confirm that yes, calling the API from a back-end service avoids the problem