[
https://issues.apache.org/jira/browse/KNOX-3530?focusedWorklogId=1050282&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1050282
]
ASF GitHub Bot logged work on KNOX-3530:
----------------------------------------
Author: ASF GitHub Bot
Created on: 26/Oct/26 13:44
Start Date: 26/Oct/26 13:44
Worklog Time Spent: 10m
Work Description: ArafatKhan2198 opened a new pull request, #1471:
URL: https://github.com/apache/knox/pull/1471
## **What changes were proposed in this pull request?**
Apache Ozone has upgraded Recon's web server from Jetty 9.4 to Jetty 12
(HDDS-8280, HDDS-16683). Jetty 12 serves `.js` files with Content-Type
`text/javascript`, where Jetty 9.4 used `application/javascript`.
The `OZONE-RECON/filter/staticLinks` filter in
`[ozone-recon/1.2.0/rewrite.xml](https://app.notion.com/p/ozone-recon/1.2.0/rewrite.xml)`
was declared only for `application/javascript`. With a Jetty 12 Recon, Knox
finds no matching filter and passes Recon's JS through unchanged. The
`/api/v1/...` links are never rewritten to
`{gateway.url}/ozone-recon/api/v1/...`, so the UI loads but every API call goes
to `https://<knox-host>:8443/api/v1/...` and fails with 404.
This PR changes the filter content type to `*/javascript`, which matches
both `application/javascript` and `text/javascript`. Knox's `MimeTypeMap`
already supports this wildcard, and the `ozone`, `ozone-scm`, `hdfsui`,
`hbaseui` and `hue` service definitions already use it.
## **How was this patch tested?**
Manual test against a Knox gateway in front of an Ozone Recon running Jetty
12.1.14:
1. **Before the fix:** Recon served its JS as `text/javascript`. The JS
fetched through Knox (`/gateway/<topology>/ozone-recon/static/js/index-*.js`)
was byte-identical to the JS served directly by Recon and still contained
`"/api/v1/clusterState"`. The Recon UI loaded through Knox, but its API calls
failed with 404.
2. Applied the change to the ozone-recon service definition on the Knox
hosts and restarted Knox.
3. Checked that the new topology deployment's `WEB-INF/rewrite.xml`
contained `<content type="*/javascript">` for `OZONE-RECON/filter/staticLinks`.
4. **After the fix:** the JS fetched through Knox contained
`"https://<knox-host>:8443/gateway/<topology>/ozone-recon/api/v1/clusterState"`,
and the Recon UI worked through Knox.
5. Regression check: against a Recon on Jetty 9.4 (serving
`application/javascript`), the rewrite was applied as before.
I also ran Knox's `MimeTypeMap` locally with a `*/javascript` key. It
matched `text/javascript`, `application/javascript` and `text/javascript;
charset=utf-8`. The old `application/javascript` key did not match
`text/javascript`.
## **Integration Tests**
No integration test was added. This is a one-line change to a service
definition. The integration suite in `.github/workflows/tests` does not run an
Ozone Recon backend, and adding one just for this case would be a large
addition. The wildcard matching this change relies on is already covered by
`MimeTypeMapTest` (e.g. `*/xml`, `*/json`).
Issue Time Tracking
-------------------
Worklog Id: (was: 1050282)
Remaining Estimate: 0h
Time Spent: 10m
> Ozone Recon UI broken through Knox: JS served as text/javascript is not
> rewritten
> ---------------------------------------------------------------------------------
>
> Key: KNOX-3530
> URL: https://issues.apache.org/jira/browse/KNOX-3530
> Project: Apache Knox
> Issue Type: Bug
> Components: KnoxSSO
> Reporter: Arafat Khan
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you open the Ozone Recon UI through Knox
> ({{{}https://<knox-host>:8443/gateway/<topology>/ozone-recon/{}}}), the page
> loads but every API call fails with 404. The browser calls
> {{https://<knox-host>:8443/api/v1/clusterState}} without the
> {{/gateway/<topology>/ozone-recon/}} prefix, so the requests never reach
> Recon. Recon itself is healthy and works fine when opened directly.
> *Root cause:*
> Knox makes Recon work behind the gateway by rewriting Recon's JavaScript
> files on the way to the browser. It adds the gateway prefix to links like
> {{{}/api/v1/clusterState{}}}. The rule that does this is in
> {{{}ozone-recon/1.2.0/rewrite.xml{}}}, and it only applies to responses with
> Content-Type {{{}application/javascript{}}}.
> Apache Ozone has upgraded Recon's web server from Jetty 9.4 to Jetty 12
> (HDDS-8280 and HDDS-16683). Jetty 12 serves {{.js}} files as
> {{text/javascript}} by default, where Jetty 9.4 used
> {{{}application/javascript{}}}. Knox doesn't match the new type, so it skips
> the rewrite and passes the JS through unchanged. The browser then calls the
> wrong URLs.
> You can see the change in Jetty's own {{{}mime.properties{}}}: Jetty 9.4 maps
> {{js=application/javascript}} and Jetty 12 maps {{{}js=text/javascript{}}}.
> * *Recon on Jetty 9.4:* the JS through Knox contains
> {{{}https://<knox-host>:8443/gateway/<topology>/ozone-recon/api/v1/clusterState{}}}.
> Works.
> * *Recon on Jetty 12:* the JS through Knox still contains the bare
> {{{}/api/v1/clusterState{}}}, exactly as Recon sent it. Fails.
> *Fix:*
> In
> {{{}gateway-service-definitions/src/main/resources/services/ozone-recon/1.2.0/rewrite.xml{}}},
> change {{<content type="application/javascript">}} to {{{}<content
> type="*/javascript">{}}}. Knox already supports this wildcard, and it matches
> both {{application/javascript}} and {{{}text/javascript{}}}. The
> {{{}ozone{}}}, {{{}ozone-scm{}}}, {{hdfsui}} and {{hue}} service definitions
> already use it.
> We tested the fix by updating the ozone-recon service definition on a Knox
> gateway in front of a Jetty 12 Recon and restarting Knox. The JS served
> through Knox then had the correct prefixed URLs, and the Recon UI worked
> through Knox.
>
>
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
