Integrating Database of Ab Initio Crystal Structures (DAICS) to Optimade

[zxwtstar]

Integrating Database of Ab Initio Crystal Structures (DAICS) to Optimade. Z. Allahyari

[merkys]

Looks legit. By the way, structure_features values do not seem to conform to OPTIMADE standard, it would probably be better to use custom prefixed field for them.

[ml-evs]

Hi @zxwtstar, just wondering if there's any progress on this? There still seems to be the issue around structure features that Andrius pointed out, plus the few comments I made over email. I am happy to merge this in the meantime to reserve the namespace, but we should probably turn off "aggregation" which will prevent this non-compliant data from being accessed in multi-provider queries, until the issues are fixed. (edit: closing the PR was accidental!)

[zxwtstar]

Dear @ml-evs I am sorry that this issue is not fixed yet. I tried to fix the problems that you mentioned once we had communicated by email, and I fixed issues in fact, but they did not appear on the database. And I couldn't fix that.
So, I got stuck for technical reasons and overloaded over time so... . I'll try to fix it again this week and if the problem persists, I appreciate it if you or your colleagues could help me solve it.

I also remember a bug, which I believe should be from the OPTIMADE side. The bug is:
Since DAICS data are available through API key generated through DAICS website for subscribed people. So, generally, people are directed through our server, and if they have a valid API key they can access the data. And everything works in this regard with our implementation.
The problem arises when users try to access data by replacing the domain or daics.net with its IP address. Then they can access all data without any required API key. Of course, we can close the corresponding ports in the firewall of our servers. But still, I was wondering if this can be solved from OPTIMADE side.

[ml-evs]

Dear @ml-evs I am sorry that this issue is not fixed yet. I tried to fix the problems that you mentioned once we had communicated by email, and I fixed issues in fact, but they did not appear on the database. And I couldn't fix that. So, I got stuck for technical reasons and overloaded over time so... . I'll try to fix it again this week and if the problem persists, I appreciate it if you or your colleagues could help me solve it.

No problem, there's no rush at all from our side, just didn't want you to think this was forgotten about from ours! Feel free to reach out over email if I can help with anything.

I also remember a bug, which I believe should be from the OPTIMADE side. The bug is: Since DAICS data are available through API key generated through DAICS website for subscribed people. So, generally, people are directed through our server, and if they have a valid API key they can access the data. And everything works in this regard with our implementation. The problem arises when users try to access data by replacing the domain or daics.net with its IP address. Then they can access all data without any required API key. Of course, we can close the corresponding ports in the firewall of our servers. But still, I was wondering if this can be solved from OPTIMADE side.

This sounds more like a server configuration issue than an OPTIMADE one. You would probably have to write some custom middleware to intercept requests and require an API key (we could add this generally too, I guess, but this will be quite dependent to your setup and how you issue keys).