zlux
zlux copied to clipboard
zowe
API Catalog not accessible in Desktop
Zowe 3.0.0, 3.1.0
Dev console:
Refused to display 'https://example.com:7777/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Log:
2025-02-21 13:49:47.035 <ZWED:393980> ZWESVUSR INFO (_zsf.install,webapp.js:2050) ZWED0299I - Loading remote iframe app org.zowe.api.catalog located at https://example.com:7777/apicatalog/ui/v1
2025-02-21 13:50:01.807 <ZWEAGW1:reactor-http-nio-2:50725835> ..35mZWESVUSR..0;39m ..36mERROR..0;39m ((javax.net.ssl)) Fatal (CERTIFICATE_UNKNOWN): PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
I suggest that the URL used in the browser has a different host:port combination than the first entry of zowe.externalDomains + zowe.externalPort
That's what is used here https://github.com/zowe/api-layer/blob/v3.x.x/api-catalog-package/src/main/resources/plugin/pluginDefinition.json#L8C19-L8C74 And if there is a mismatch, the Desktop's going to try accessing that URL, but then the browser will say "you cant do that, its not same-origin!"
I have found this problem occurring for 2 scenarios:
App-server port
When accessing the Zowe Desktop via components.app.server.port.
HA
When HA is used, we have setting like this:
zowe:
externalDomains: example1x.com
haInstances:
ha10:
hostname: example10.com
ha15:
hostname: example15.com
In both cases is true, that different combination of zowe.externalDomains + zowe.externalPort was used.
@Martin-Zeithaml it looks like the problem occurs as a result of 2 things
- the above discussion about how the desktop chooses which URL to reach given what the pluginDefinition says
- "X-Frame-Options: sameorigin" was apparently added to the api-catalog in v3. it isn't in the v2 network response. So it has some restriction in v3 which triggers hostname:port sensitivity.
and a third thing...
if I access app-server from hostname:port, it tries to access api-catalog from hostname:port/ui/v1/api-catalog That actually seems like the right behavior!
... and then APIML responds with an HTTP 302 to hostname.domainname.com:port/ui/v1/api-catalog
... and that's incompatible with the header they send, because that's not considered sameorigin.
So, I don't really consider this a bug of any of the zlux codebase. Looks like APIML shouldn't be doing the 302, or the 302 should be done to zlux as well so that the URLs align.
... But the gateway doesn't do the same sort of 302 when going to hostname:port/zlux/ui/v1 So I'm guessing this is a 302 that the catalog does for some reason?
I have isolated the cause to a catalog behavior change that can be fixed by changing its pluginDefinition.json here https://github.com/zowe/api-layer/pull/4007