radar-hub: accept an http localhost publicURL again (1.9.1-rc.1)

[hisco]

Chart 1.9.0 refuses hub.publicURL=http://localhost:<port> when nothing fronts the hub:

hub.publicURL "http://localhost:18080" is a localhost address opened with kubectl port-forward, which reaches the web Service's https port - use an https URL

The premise is wrong. The web Service always has the plain-http port 80, and kubectl port-forward svc/radar-hub-web 18080:80 opens the hub. 1.8.0 installed this way, and radar-e2e does, so every radar-e2e job has failed at helm install since 1.9.0.

What changes:

• The https-only check is gone. In port-forward mode the URL must be http or https. http is refused only for 0.0.0.0 and [::], where port-forward listens on every interface and sign-in would travel in plain text.
• The install notes forward an http:// URL to the Service port named http, and show the "accept the self-signed certificate" step only for https.
• The web.tls.selfSigned requirement in port-forward mode stays. Its message now gives the real reason: other clusters reach the hub only through the self-signed listener, and the hub adds insecureSkipVerify to their install commands only when it is on.
• values.yaml documents both forms. https stays the recommended one.

Version: staged as 1.9.1-rc.1 on Hub 1.9.0. Hub 1.9.1 carries the matching fix to the port-forward command in invites and emails (it has the same https-only assumption), and its release promotes this chart to 1.9.1. Until then, the rc with an http URL prints correct install notes, but the hub's invites still say :443.

Tests: tests/render-matrix.sh passes, with new cases for http on localhost / 127.0.0.1 / [::1], refusals for http on 0.0.0.0 and [::] and a non-http scheme, and the notes' http target. helm unittest passes. radar-e2e run.sh installs this chart with http://localhost:18080 and its cluster connects.

---

Note

Medium Risk
Changes install-time URL validation and port-forward instructions; allowing plain http is limited to loopback hosts but still affects how operators expose the hub locally.

Overview
Re-enables http:// loopback hub.publicURL for kubectl port-forward after 1.9.0 incorrectly required https and broke installs (e.g. radar-e2e).

Validation in secret.yaml no longer rejects all plain-http localhost URLs. Port-forward mode now requires http or https; http is blocked only for 0.0.0.0 and [::] so sign-in is not exposed on every interface. The web.tls.selfSigned guard for loopback without Ingress/LB remains, with clearer messaging about agents and self-signed TLS.

Install notes (NOTES.txt) pick the web Service target from the URL scheme: https → tls port; http → named port http, and the self-signed certificate hint appears only for https.

values.yaml documents both localhost forms (https recommended). Chart version is 1.9.1-rc.1; render-matrix.sh adds render/refuse and NOTES assertions for the new behavior.

^{Reviewed by Cursor Bugbot for commit 4b1fced. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restore HTTP localhost port-forward installs for radar-hub

🐞 Bug fix 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Allow HTTP loopback URLs again while rejecting plaintext port-forwards bound to every interface.
• Match install-note port-forwards to the URL scheme; retain self-signed TLS for cluster
 connections.
• Document both options and test URL validation and rendered instructions.

Diagram

graph TD
  A["Public URL"] --> B{"Port-forward valid?"} -->|yes| C{"URL scheme?"} -->|http| D["HTTP port"] --> F["Web Service"]
  C -->|https| E["HTTPS port"] --> F
  B -->|no| G["Reject install"]

Loading

High-Level Assessment

Use the web Service’s existing named HTTP port for HTTP loopback URLs. Requiring HTTPS for every port-forward would preserve the regression; removing the self-signed requirement would break the HTTPS path used by other clusters.

Files changed (5) +44 / -17

Bug fix (2) +23 / -11

NOTES.txtChoose the port-forward target by URL scheme +4/-3

Choose the port-forward target by URL scheme

• HTTP URLs now forward to the web Service’s named http port; HTTPS URLs continue to use its configured TLS port. Certificate-acceptance instructions appear only for HTTPS.

charts/radar-hub/templates/NOTES.txt

secret.yamlPermit safe HTTP loopback port-forwards +19/-8

Permit safe HTTP loopback port-forwards

• Replaces the HTTPS-only guard with HTTP-or-HTTPS validation and rejects plaintext URLs bound to 0.0.0.0 or [::]. Keeps the self-signed TLS requirement and explains its role in other clusters’ connections.

charts/radar-hub/templates/secret.yaml

Tests (1) +13 / -2

render-matrix.shCover HTTP loopback validation and install notes +13/-2

Cover HTTP loopback validation and install notes

• Adds successful HTTP loopback cases and refusals for wildcard binds, unsupported schemes, and missing self-signed TLS. Verifies HTTP and HTTPS port-forward targets and certificate instructions.

charts/radar-hub/tests/render-matrix.sh

Documentation (1) +7 / -3

values.yamlDocument HTTP and HTTPS port-forward options +7/-3

Document HTTP and HTTPS port-forward options

• Explains supported loopback HTTP hosts, the wildcard-address restriction, and the continuing self-signed TLS requirement. Recommends HTTPS.

charts/radar-hub/values.yaml

Other (1) +1 / -1

Chart.yamlStage chart version 1.9.1-rc.1 +1/-1

Stage chart version 1.9.1-rc.1

• Bumps the chart version from 1.9.0 while retaining Hub appVersion 1.9.0.

charts/radar-hub/Chart.yaml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (2) 📜 Skill insights (0)

1. Invites forward HTTP to HTTPS 🔗 Cross-repo conflict ≡ Correctness

Description

radar-hub 1.9.0 builds invite port-forward commands from the in-cluster agent URL, so it selects
the HTTPS Service port even when this chart now permits an HTTP localhost URL. With
hub.publicURL=http://localhost:18080, invite emails and the radar-hub-web invitation screen tell
invitees to forward 18080:443 and open an HTTP link, unlike the chart's working 18080:http
install note.

Code

charts/radar-hub/templates/secret.yaml[R83-85]

+{{- if and $portForward (ne $scheme "http") (ne $scheme "https") -}}
+{{- fail (printf "hub.publicURL %q must start with http:// or https://, e.g. https://localhost:8443." .Values.hub.publicURL) -}}
+{{- end -}}

Evidence

The chart permits HTTP localhost and forwards it to the named HTTP port, but still selects Hub
1.9.0. That Hub constructs the command using the in-cluster TLS port; its command is passed into
invitations and exposed to the web invitation screen.

helm-charts -> radar-hub
helm-charts -> radar-hub-web
charts/radar-hub/templates/secret.yaml[81-89]
charts/radar-hub/templates/NOTES.txt[79-82]
charts/radar-hub/Chart.yaml[5-11]
External repo: skyhook-dev/radar-hub, internal/server/local_cluster.go [390-426]
External repo: skyhook-dev/radar-hub, internal/server/api.go [3155-3166]
External repo: skyhook-dev/radar-hub-web, src/pages/OrgMembers.tsx [168-191]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chart accepts HTTP localhost URLs, but its pinned Hub image generates invite commands that forward to HTTPS.
## Fix Focus Areas
- charts/radar-hub/Chart.yaml[5-11]
- charts/radar-hub/templates/NOTES.txt[79-82]
- /cross_repos/radar-hub/internal/server/local_cluster.go[390-426]
## Recommended Fix
Update Hub's invite command generation to select the browser-facing Service port from the public URL scheme, and ship a compatible Hub image with the chart before enabling HTTP localhost installations.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Operators are told not to use HTTP ✓ Resolved

Description

The hub.publicURL comments now describe a supported HTTP localhost setup, but the preceding
guidance still says the URL “MUST be https://” and that nobody can sign in over HTTP. Operators
consulting values.yaml for the newly supported port-forward setup receive contradictory
instructions about whether to use it.

Code

charts/radar-hub/values.yaml[R140-143]

+  # https (e.g. https://localhost:8443) forwards to the self-signed https
+  # port and is the recommended form. http forwards to the http port and
+  # works on localhost, *.localhost, 127.x.x.x and [::1] in browsers that
+  # accept Secure cookies over http on those hosts (tested in Chromium-based

Evidence

The existing guidance at lines 122–131 requires HTTPS and says HTTP prevents sign-in; the added
guidance at lines 140–144 recommends an HTTP port-forward option for loopback hosts. The new chart
validation explicitly permits that option.

charts/radar-hub/values.yaml[122-144]
charts/radar-hub/templates/secret.yaml[81-89]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `hub.publicURL` guidance says all HTTP URLs prevent sign-in, contradicting the new localhost HTTP instructions below it.
## Fix Focus Areas
- charts/radar-hub/values.yaml[121-144]
## Recommended Fix
Qualify the HTTPS requirement and sign-in warning so they apply to non-loopback public URLs, while keeping the new localhost HTTP instructions consistent with that exception.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Installation guides reject working HTTP 🔗 Cross-repo conflict ≡ Correctness

Description

radar-docs says hub.publicURL must use HTTPS and that HTTP prevents sign-in and cluster
connections, while the chart now documents and accepts HTTP loopback URLs with self-signed TLS
enabled. Someone following the configuration or troubleshooting guide for this chart is therefore
told to abandon the supported localhost port-forward setup.

Code

charts/radar-hub/values.yaml[R140-144]

+  # https (e.g. https://localhost:8443) forwards to the self-signed https
+  # port and is the recommended form. http forwards to the http port and
+  # works on localhost, *.localhost, 127.x.x.x and [::1] in browsers that
+  # accept Secure cookies over http on those hosts (tested in Chromium-based
+  # browsers); 0.0.0.0 and [::] need https.

Evidence

The new chart value comments explicitly support HTTP loopback, whereas both cross-repository guides
state that HTTP cannot be used for sign-in.

helm-charts -> radar-docs
charts/radar-hub/values.yaml[135-145]
External repo: skyhook-dev/radar-docs, cloud/self-hosted/configuration.mdx [20-42]
External repo: skyhook-dev/radar-docs, cloud/self-hosted/install.mdx [279-286]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The self-hosted guides categorically reject HTTP public URLs despite the chart's new localhost exception.
## Fix Focus Areas
- charts/radar-hub/values.yaml[135-145]
- /cross_repos/radar-docs/cloud/self-hosted/configuration.mdx[20-42]
- /cross_repos/radar-docs/cloud/self-hosted/install.mdx[279-286]
## Recommended Fix
Update both radar-docs guides to distinguish unsupported public HTTP exposure from supported HTTP loopback port-forwarding with web.tls.selfSigned enabled.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗