About modal does not show server version and build info

[mihailefter]

Just noticed that the About modal always shows - for the server version and build info. This seems to be caused by a CORS issue on /actuator/info, so it probably needs to be fixed on the backend side.

Also noticed that the root Turtle metadata exposes the FDP software version, so we could also fallback to it. However, there does not seem to be an equivalent value there for the build timestamp.

[dennisvang]

For reference, here are the HTTP headers from an exchange with http://localhost:8088/actuator/info running locally as Docker containers.

Click to see HTTP headers

request

GET /actuator/info HTTP/1.1
Host: localhost:8088
User-Agent: [...] Firefox/155.0
Accept: application/json
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Referer: http://localhost/
Origin: http://localhost
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Priority: u=0
Pragma: no-cache
Cache-Control: no-cache

response

HTTP/1.1 200 
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json
Content-Length: 91
Date: Tue, 08 Sep 2026 09:17:38 GMT
Keep-Alive: timeout=60
Connection: keep-alive

A quick summary of the problem:

CORS is triggered because the FDP UI is served from http://localhost whereas the FDP API is served from http://localhost:8088.
The browser notices the different origin, i.e. different combination of uri-scheme, uri-host, and uri-port (rfc6454), so it sends an Origin header with the request.
In response to the Origin header, the server should return an Access-Control-Allow-Origin header.
However, for some reason, the server does not send this header.
As a result, CORS is denied by the browser. In other words, the response body is received perfectly fine, but the browser does not expose it to the javascript application.

In the original FDP-client this issue did not arise because all traffic was routed through the reverse-proxy built in to the fairdatapoint-client image, so the /actuator/info request was same-origin instead of cross-origin.

The question is why the server does not respond properly, but that's an issue for FAIRDataTeam/FAIRDataPoint.

[dennisvang]

[...] This seems to be caused by a CORS issue on /actuator/info, so it probably needs to be fixed on the backend side.

@mihailefter you're right. I'll try to tackle this issue in the FDP API. Nevertheless, it will take a lot of time for a fix to propagate. Lots of people continue to serve outdated versions of the API, unfortunately.

Also noticed that the root Turtle metadata exposes the FDP software version, so we could also fallback to it. However, there does not seem to be an equivalent value there for the build timestamp.

Sounds good: Falling back on the RDF statement would take care of the immediate problem and would make things a bit more robust and backward compatible.

Note

There is also a way to tackle this problem on the operations side, by serving the backend and frontend from the same origin.
That's a matter of reverse-proxy configuration (also see #86).