CORS not working

[waldenn]

I think CORS is not configured properly to use the Fatcat API, I get the following error (and JSONP is also not working for me).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://scholar-qa.archive.org/search/?q=lang%3Aen+Wikipedia (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Could you enable CORS on the API server? See: https://ubiq.co/tech-blog/enable-cors-apache-web-server/

Thanks in advance!

[bnewbold]

Indeed! Thanks for reporting.

I don't have any intention of adding JSONP support. The fatcat API itself (api.fatcat.wiki) should work with CORS, but of course doesn't include the full search stuff.

Please note that that we will be changing the domain at some point, probably to scholar.archive.org, and the scholar-qa domain will redirect or be a staging area, which could break CORS again.

[bnewbold]

Also, if you are planning to do an integration, we will probably make the scholar ("full-text") content available through https://search.fatcat.wiki as a separate index. This endpoint exposes the raw elasticsearch API (behind a proxy, es-public-proxy), which might be easier to develop with. In both cases we aren't yet offering any long-term API stability guarantees, as this is still an "alpha" service.

[waldenn]

Ok, excellent. I will plan on using the raw Elasticsearch API. Thanks for all the hard work!

[bnewbold]

I think the CORS issue is fixed now, for a minimal set of headers, GET requests, and any Origin. At least, testing naively with:

curl -I -X OPTIONS \
  -H "Origin: http://EXAMPLE.COM" \
  -H 'Access-Control-Request-Method: GET' \
  https://scholar-qa.archive.org/search

Seems to work as expected, I didn't test with a real cross-domain browser request.

I also catch the case of an API call with no q parameter and return a 400 error for that, though this isn't expressed correctly in the OpenAPI spec. Using FastAPI for both an API and web serving is sort of weird.

[waldenn]

Great! I tweeted about the integration here. Such a cool project!

Nitpick issue I saw: The returned results also highlights ("_highlights") the search-language. I think this is not really needed / useful, but may just be a technical issue on the backend.

[bnewbold]

Yes, the highlights are included (undocumented) because I am basically passing back exactly the query results that would be used in the web interface.

That could be controlled for API calls via a query parameter though. If you are interested in that, could you create a new issue?

[waldenn]

Done: #54