feat(ui-react): allow Domain on web endpoint without enabling TLS

[gustavosbarreto]

Refs #6322.

What

Decouples the hostname field in the React Web Endpoint create drawer from the TLS toggle, renames it to Service hostname to drop the ambiguous Domain label that suggested a public URL, and aligns the surrounding microcopy. The create payload now sends the tls object whenever either the toggle is on or a hostname is set.

Why

The backend now treats tls.domain as a Host override even when tls.enabled is false (see #6321). This is the configuration users need to reach plain-HTTP services on a device that validate Host or auto-redirect to a canonical hostname. The previous UI gated the field on the TLS toggle and stripped it from the payload, so that combination was unreachable from the console.

The original Domain label also led to a recurring misunderstanding where the field was filled with the user's internal hostname under the assumption that it controlled the public endpoint URL.

Changes

• The hostname input is rendered outside the TLS-gated block. FQDN validation runs whenever the field is filled.
• An asterisk appears next to the field label when TLS is enabled, mirroring the backend rule that tls.domain is required in that case.
• Create payload includes tls when tlsEnabled || hostname != "". tls.enabled carries the actual toggle value.
• New section header TLS matches the badge shown on existing endpoints (TLS) and the empty-state card (Device-side TLS).
• Toggle text reads Service on the device uses HTTPS, with a hint clarifying the toggle controls only the proxy-to-service leg, not the public URL scheme.
• Field is now labeled Service hostname with a hint describing both roles (Host header override; SNI when the service uses HTTPS).
• Error message says Enter a valid hostname (e.g. app.example.com).

Out of scope

The legacy Vue UI under ui/ has the same gating issue but is being phased out and is not addressed here.

Related

• Web endpoint TLS-to-backend regression: code dropped during V2 multistream refactor #6316, shellhub-io/cloud#2368, shellhub-io/cloud#2369: prerequisite fixes for the Web Endpoint feature itself, already merged.
• Web endpoint: allow Host override independent of TLS to support backends that validate canonical hostname #6319 / feat(ssh): use tls.domain as Host override even when TLS is disabled #6321: backend Host-override that this PR exposes in the UI.

[github-actions]

Claude finished @gustavosbarreto's task in 6m 38s —— View job

---

Code Review Complete

Reviewed 1 file across code quality, security, testing, TypeScript/React patterns, and architecture (including cross-repo impact against the cloud backend) — no issues found. The code looks good as-is.

Key observations from the review:

• The new payload shape { tls: { enabled: false, verify: false, domain: "..." } } is fully compatible with the backend stack — the cloud service, SSH proxy handler, OpenAPI spec, and data model all handle this combination correctly.
• Validation logic correctly requires a valid FQDN whenever tlsDomain is non-empty (regardless of TLS toggle) and requires tlsDomain when TLS is enabled.
• No security concerns — the domain field is FQDN-validated both client-side and server-side, and is only used for a Host header override on an internal proxy-to-device connection.
• No existing tests for WebEndpoints.tsx exist in the repo, so no tests need updating.

---

To request another review round, comment /review.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 5m 56s —— View job

---

Code Review Complete

Reviewed 1 file across code quality, security, testing, TypeScript/React patterns, and architecture (including cross-repo impact against the cloud backend) — no issues found. The code looks good as-is.

Key observations from the review:

• The new payload shape { tls: { enabled: false, verify: false, domain: "..." } } is fully compatible with the backend stack — the cloud service validation, SSH proxy handler, OpenAPI spec, and data model all handle this combination correctly. The verify field is only consumed when enabled is true, so sending it when TLS is off is harmless.
• Validation logic correctly requires a valid FQDN whenever tlsDomain is non-empty (regardless of TLS toggle) and correctly blocks submission when TLS is enabled but domain is empty. Both client-side (isValidFQDN regex) and server-side (validate:"omitempty,fqdn" tag) enforce consistent FQDN format.
• No security concerns — the domain field is FQDN-validated on both sides, restricting the character set to [a-zA-Z0-9.-], which prevents Host header injection and CRLF attacks. The field only affects the Host header on an internal proxy-to-device connection, not the connection target itself.
• No existing tests for WebEndpoints.tsx exist in the repo (predates this PR), so no tests need updating.

---

To request another review round, comment /review.