TLS certificates page: ACME settings tab with challenge type selection

[stephdl]

NethServer/dev#8099

Description

The TLS certificates page had a separate ACME servers page, reachable through a top-right navigation button. The ACME challenge type was already accepted by the traefik set-acme-server action but was not exposed anywhere in the UI, so administrators who need TLS-ALPN-01 (typically when port 80 is unavailable or filtered) had to edit traefik.yaml by hand.

This PR merges the two pages into one and exposes the challenge type.

• The navigation button is replaced by two tabs, Certificates and ACME settings.
• The ACME settings table columns are now Node, ACME directory URL, Challenge type. The node comes first, which also fixes the previous wrong column order.
• The challenge type is shown per node as a tag and is selectable in the edit modal through a required radio group, with HTTP-01 and TLS-ALPN-01.
• The old /settings/acme-servers path redirects to /settings/tls-certificates?view=acme, so existing bookmarks and links keep working.
• Labels follow the mockups: ACME server becomes ACME settings, Edit ACME server becomes Edit ACME settings.

Settings remain per node, as before.

No backend change is needed: set-acme-server already validates challenge against the ["TLS-ALPN-01", "HTTP-01"] enum, and get-acme-server already returns it.

Extensibility

The options come from a single ACME_CHALLENGE_TYPES array exported by EditAcmeServerModal.vue, which drives the radio group, the tag colour and the labels. Adding DNS-01 later means adding one entry and one translation key. DNS-01 is intentionally left out of this iteration, as it needs extra configuration fields.

Trusted proxy settings are not part of this PR: they will be exposed on the HTTP routes page and are tracked separately.

Robustness

An internal review pass raised a number of issues that are addressed in the same commits.

Tab selection is validated against a known list. q.view is normalised through a TAB_VIEWS constant in both route guards. Previously only an empty value was defaulted, so ?view=certificate (a stale or mistyped link) left cv-tabs with no selected child — and because noDefaultToFirst is set, both panels kept their hidden attribute and the page body was empty. A same-path navigation whose query omits view now also resets to the first tab instead of keeping whatever tab was open.

The ACME tab mounts once and stays alive. It was gated by v-if="q.view === 'acme'", which destroyed and recreated the child on every tab switch and re-issued one list-installed-modules cluster task plus one get-acme-server module task per node each time. A first-visit latch replaces it, so the chain runs once and the table's search, sort and page survive a switch.

Task listeners are torn down. AcmeSettings.vue and EditAcmeServerModal.vue registered $root.$once handlers with no beforeDestroy. Leaving the tab mid-flight ran a completion handler on a dead instance, which fanned out into one module task per node, and a save completing after the modal was gone silently lost its refresh. Both now record [eventName, handler] pairs and $off them. This is safe because src/mixins/notification.js only emits those names — all notification and drawer bookkeeping is store-driven and independent of listeners.

The table error state clears. Nothing ever reset error.getAcmeServer, so one temporarily offline node left the table showing the error banner instead of rows, even after every node answered again. A clearTableError() helper now runs at the start of each load. The list-installed-modules error branch also resets its loading flag, which it previously left stuck at true.

The challenge field error is visible. The message lived in a bare .bx--form-requirement div, which Carbon keeps at display: none unless it follows a [data-invalid] field wrapper — something a radio group never is. A validation failure on challenge therefore showed nothing at all. The div now carries a class that forces visibility and the error colour.

Only reported fields are sent back. The payload is built incrementally and echoes back challenge only when the module reported one, and email only when it is defined. Since the action schema sets additionalProperties: false, sending a key an older traefik does not know about would have failed the whole request. For the same reason the Challenge type block is hidden when the module reported no challenge type, so opening the modal to correct the URL can no longer silently switch that node to HTTP-01.

Unknown validation parameters no longer throw. setAcmeServerValidationFailed blindly assigned this.error[param] and called focusElement(param). With email now in the payload, a validation error on it would have written a non-reactive key and called .focus() on an undefined ref. Parameters without a field of their own are routed to the modal-level error notification instead.

Surviving the Traefik restart

set-acme-server ends with systemctl --user restart traefik.service, and Traefik is what serves the cluster admin UI and its websocket. So saving ACME settings drops the admin's own connection, and the set-acme-server-completed event that carries the table refresh travels on that very socket. It is lost: the table kept showing the old URL and challenge type, and the loading counters never returned to zero, leaving skeleton rows until the page was reloaded by hand. That is what the earlier Reload required warning was working around.

The Certificates tab has the same problem. delete-certificate and set-certificate also restart Traefik, through cert_helpers.purge_acme_json_and_restart_traefik — the helper writes the unit as traefik, not traefik.service, which is easy to miss when grepping.

Both tabs now watch the Vuex isWebsocketConnected flag, which App.vue already maintains and which no component on this page read: on reconnection they reset the counter and read their data again. Decrements are clamped with Math.max(0, n - 1) and the ACME rows are keyed by Traefik instance, so an event delivered after a reset can neither unbalance the counter nor duplicate a row. The edit modal clears its pending state on reconnection as a safety net. No manual reload is needed any more, so the Reload required warning is gone.

The modal still closes on validation-ok rather than on task creation. The ACME URL is validated server-side against "format": "uri" while the client only checks non-empty, so closing earlier would throw away the inline error for a malformed URL. validation-ok is emitted before the config is written, so it arrives ahead of the restart.

The restart warning is no longer gated on the leader node. It was shown only when server.nodeId == leaderNode.id, yet the restart happens on whichever node is edited — editing a worker restarted its Traefik with no warning at all. The warning is now shown for every node, names it, and says the page reconnects on its own. This matches how the rest of the page already works: DeleteObsoleteCertificatesModal.vue shows its restart warning unconditionally, and the delete-certificate warning is gated on currentCertificate.type === 'internal' — that is, on whether a restart actually happens, never on which node.

This borrows the mechanism from #1258, which solved the same problem on the HTTP routes page. Since that PR is not merged, the pattern is currently duplicated on two branches; a shared mixin is the natural follow-up once both land.

Included fix

The edit modal used to send only url. Since the action does email = request.get("email", ""), every save silently cleared the notification email. The modal now sends back the email returned by get-acme-server.

Commits

The first commit only re-indents the certificates table to wrap it in a tab panel, no logic change. It is easier to read with whitespace hidden.

1. refactor(ui): merge ACME servers view into TLS certificates tabs
2. feat(ui): add ACME challenge type selection
3. fix(ui): preserve ACME email when saving settings
4. style(ui): shorten comments in the ACME settings UI
5. feat(ui): recover the TLS certificates page after a Traefik restart

Design

Mockups: Figma, design issue NethServer/dev#7973.

Testing

core/ui has no test runner configured, so this was checked with lint and a production build only, on the final tree and on each intermediate commit. All pass.

Still to verify on a cluster:

• Tab navigation works both ways, and the URL follows (?view=certificates / ?view=acme)
• Reloading on ?view=acme lands on the ACME tab
• An unknown value such as ?view=certificate falls back to the Certificates tab instead of an empty page
• Navigating to the same path without view while the ACME tab is open lands on Certificates
• /settings/acme-servers redirects correctly
• The Nodes page deep link (?selectedNodeId=...) still filters the certificates table
• Flipping tabs several times issues the ACME task chain only on the first visit, and search/sort/page survive the switch
• Opening the ACME tab and leaving immediately fires no get-acme-server burst afterwards
• Table shows the correct column order and the current values per node, and the tag matches traefik.yaml
• The edit modal saves both the ACME directory URL and the challenge type, and the values survive a page reload
• A challenge validation error shows a visible message under the radios
• Radios are disabled while the save is in flight
• Stopping one traefik to get the error banner, restarting it and saving on another node brings the rows back
• The notification email is not cleared by a save, checked with api-cli run module/traefik1/get-acme-server
• With an invalid stored email, the error surfaces in the modal with no console TypeError
• Against a traefik whose get-acme-server omits challenge, the block is hidden, a URL-only save succeeds and the challenge type is not rewritten
• An empty URL shows the Required message
• Certificate management on the Certificates tab is unchanged

The restart handling needs the browser connected through the node being edited, since editing any other node does not drop your session:

• The modal warns that Traefik will be restarted and names that node — on a worker as well as on the leader
• Save, then do not touch the browser: the websocket drops and reconnects, and the table refreshes on its own with the new URL and challenge type, no skeleton left, no manual reload
• Reload the page by hand during the restart and let it settle: both tabs end up populated, neither stuck on skeleton rows
• Delete an internal certificate on the connected node: the Certificates tab recovers the same way
• A malformed ACME URL still shows its inline error and keeps the modal open
• No duplicate rows in either table after a reconnection

The connected/disconnected toasts may churn for a while — that is the pre-existing vue-native-websocket double-reconnect issue described in #1258, untouched here. What matters is that the page recovers its data without intervention.

Follow-up

Out of scope here, worth separate issues:

• views/Backup.vue and components/domains/DomainUsersAndGroups.vue use the same q.view + noDefaultToFirst pattern and carry the same two tab-selection bugs.
• getAcmeServer() has no re-entrancy guard, so two closely spaced saves can still interleave. Rows can no longer be duplicated now that they are keyed by Traefik instance, and the clamped decrement keeps the counter sane, but a batch token would be cleaner.
• The isWebsocketConnected recovery is duplicated between this page and the HTTP routes page of Add Frontend proxies tab to the HTTP routes page #1258. Once both are merged it belongs in a shared mixin.
• set-acme-server and get-acme-server are granted to no role in ns8-traefik, so a delegated certadm user probably cannot use this tab.
• get-acme-server infers the challenge type only from httpChallenge.entryPoint and ignores tlsChallenge, so a hand-edited traefik.yaml can make the UI display the wrong tag.