CORS error consuming service from ebi.ac.uk domain

[nestor-diaz]

Hi all, We're migrating BioStudies / Submission Tool to use the new platform endpoints but there is a CORS error consuming them from localhost and ebi.ac.uk (http://ves-hx-f2.ebi.ac.uk). These are the endpoints we're trying to use:

https://registry.api.identifiers.org/restApi/namespaces
https://registry.api.identifiers.org/restApi/namespaces/search/findByPrefixContaining?content=x

It would be great if the team could help us whitelisting them somehow so we can use the platform locally and in our development environments.

Thanks in advance.

---

With this CURL you'll be able to reproduce the issue:

curl -s https://registry.api.identifiers.org/restApi/namespaces -H 'Origin: https://wwwdev.ebi.ac.uk/biostudies/submissions'

[mbdebian]

Thanks for reaching out @ndiaz-candido , exactly, our CORS configuration only allows origins from identifiers.org domains. Let's have a chat around the production domains your submission tool is using, so that we can take action regarding the registry API. In relation to the development environment, there's a docker-compose based solution we could provide you to run the registry locally, so you can perform any integration tests you need. Cheers, Manuel

[nestor-diaz]

Thanks Manuel! Reviewing the repository I see this file https://github.com/identifiers-org/cloud-hq-ws-registry/blob/master/docker-compose-development.yml, is it the docker-compose file I should use to run the platform locally?

Regards, Néstor

[mbdebian]

That’s the one we use as development environment for the registry API microservice itself, so it won’t bring a registry up and populate its content. We have to write a new one for bringing up the registry API with all its dependencies, and some development data, so you can use it for your development environment. For other services, like the resolution API, we had this already written, so the community could run them locally, but we haven’t prepared that for the registry API, as we had no use case for it until now. Regards, Manuel

[nestor-diaz]

Hi Manuel - thanks for the explanation. For local development we can wait or use our development environment but we're seeing the CORS error in production and it's kind of showstopper for new submissions. We really appreciate if you can help us with this as soon as you can.

This is our production URL https://www.ebi.ac.uk/biostudies/submissions.

[mbdebian]

Hi @ndiaz-candido , sorry I didn’t see this comment yesterday, I’ll get this fixed today. Thanks, and sorry again for the delay

[nestor-diaz]

No worries @mbdebian and thanks a lot for your help!

[mbdebian]

Hi @ndiaz-candido , I just updated our production deployment to whitelist your production URL in CORS, it should be working now. Please, don't hesitate to let me know if you find any problem Cheers, Manuel

[nestor-diaz]

Thanks a lot @mbdebian, I'm testing in our dev environment that's running on http://ves-hx-f2.ebi.ac.uk:8120 and it's still getting 403 with a Invalid CORS request response. Should we wait until the changes get deployed or is it because it's a subdomain?

This is the request information:

Regards, Néstor

[mbdebian]

Hi @ndiaz-candido , that’s normal, I opened CORS for your production URL, https://www.ebi.ac.uk/biostudies/submissions, as indicated in your previous comment. Is it working for your production environment? Regarding your development environment, please allow me a few days for preparing a docker-compose based file that will launch a registry locally, for you to test, as VM FQDNs at the EBI are ephemeral (or meant to be), and they may change in the future. Meanwhile, please, feel free to have a look at how we deploy the registry on Kubernetes, which is a mechanism that we also released under MIT license, and docker-compose related information could also be derived from there. https://github.com/identifiers-org/cloud-devops-hq Thanks again for reaching out @ndiaz-candido , and please, don’t forget to let me know if the change I made to CORS is working for your production environment, at the given URL https://www.ebi.ac.uk/biostudies/submissions, and if you have any other issues.

[mbdebian]

I will also re-open this issue until I hear from @ndiaz-candido

[nestor-diaz]

Thanks @mbdebian, we haven't deployed the changes in prod, we had to change the app to use the new platform but they aren't still in production. I would like to test somehow that our changes work with the new platform maybe mocking at code level the response. I'll try and will let you know as soon as we can move those changes to production. Regards, Néstor

[mbdebian]

I can give you a hand with that, if you could provide your development URL (other than localhost), I can temporarily open CORS for that URL as well, that way you can run your tests easily. Thanks, Manuel

[nestor-diaz]

That would help a lot! This is our development URL http://ves-hx-f2.ebi.ac.uk:8120/submissions. Thanks @mbdebian for your outstanding help.

[mbdebian]

Hi @ndiaz-candido , I have added your development URL, http://ves-hx-f2.ebi.ac.uk:8120/submissions as indicated in the previous comment, to our CORS production configuration, and it should now be live on the platform. Could you please confirm it works for your development environment? Thanks! ^_^

[nestor-diaz]

Hi @mbdebian, unfortunately not, I got the same error :(

We're hitting this URL: https://registry.api.identifiers.org/restApi/namespaces And Origin in the request is http://ves-hx-f2.ebi.ac.uk:8120 (our dev environment) which is the same I provided you.

[mbdebian]

Hi again @ndiaz-candido , I’m afraid that the URL you gave me is “http://ves-hx-f2.ebi.ac.uk:8120/submissions”, when it comes to CORS, the full Origin URL is important, give me a few minutes and I will remove ‘/submissions’ from that URL in our production environment, so it matches your ‘Origin’ real value. Thanks, Manuel

[nestor-diaz]

Sorry about that @mbdebian , let me know to test again. Many thanks, Néstor

[mbdebian]

Changed! I hope this is the one Cheers, Manuel

[nestor-diaz]

Yeah! It works now. Thanks a lot @mbdebian . I'm gonna test the changes and let you know if it works in production too.

[mbdebian]

Cheers!

[nestor-diaz]

Hi @mbdebian, sorry for bothering you again. I found out that we use the resolver api to get the provider URL of a resource.

In the old platform we used to use https://identifiers.org/rest/identifiers/validate/${prefix}:${id} but looks like that endpoint was moved to the resolver api. I'm assuming it based on the new platform documentation and please correct me if I'm wrong. In the new platform, to get the provider URL I'm hitting this URL https://resolver.api.identifiers.org/${prefix}:${id}.

I went through the registry documentation and didn't find an endpoint to get the same behaviour.

If my assumptions are correct, could you please help us adding our URLs to the resolver api?

The URLs (I took them exactly as they appear in Origin attribute):

https://www.ebi.ac.uk
http://ves-hx-f2.ebi.ac.uk:8120

Thanks in advance!