3 Commits (v1.3.38)

Author	SHA1	Message	Date
nexxo	712803edd6	Serve the custom domain, not just announce it ... A verified custom domain was reported as the customer's address by Instance::address(), by the portal and by the credentials mail while nothing on the platform routed it: the Traefik router's rule was hard-coded to {subdomain}.{zone}. The address a customer was handed answered nothing, and a withdrawn domain stayed in Nextcloud's trusted_domains forever, because the only thing that ever wrote either was the initial provisioning run. - TraefikWriter::write() takes a LIST of hostnames under one stable router name — the platform address always, the verified domain as well when there is one. One file per instance, so a withdrawal is a rewrite rather than a second thing somebody has to remember. - ConfigureDnsAndTls records the custom domain's certificate instead of waiting on it: it depends on an A record in the customer's own zone, which may never appear, and must never fail a run. The platform address keeps its 840s deadline. instances.domain_cert_ok tells "proven" apart from "answering", and the portal now says which. - ConfigureNextcloud deletes trusted_domains 2 when there is no verified domain, so a withdrawn one stops being trusted. - New `address` pipeline (those two steps) plus ReapplyInstanceAddress, which starts one against the order and refuses to start a second while any run is in flight. The route is rewritten when the hostname list differs from what the router carries — not on route_written, which would short-circuit exactly the case a re-apply exists for. - Triggered where the address changes: verification flipping either way in clupilot:verify-domains, the customer's own domain page, and CustomDomainAccess::deactivate() on a package downgrade. - A maintenance run no longer condemns its subject: an address run that failed used to mark the order failed and release the live instance with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:44:52 +02:00
nexxo	4e3beca759	Close the domain page to packages that may not have one ... The rule was decided in CustomDomainAccess but nothing asked it on the way in: /domain answered every customer on every package, so the entry package could set a domain it is not sold and cannot keep. The guard sits in mount(), not on the route. A Livewire component answers POSTs to /livewire/update by itself, so a route-only check would have left save() and the rest reachable to exactly the customers it was meant to stop. The sidebar asks the same question through a gate rather than a second copy of the rule — a customer holds no permissions at all (R21 puts all seventeen on the operator guard), so can() had nothing to filter on and the tab was shown to everyone, leading straight into the 403 the page now raises. Customer::forUser() carries the resolution the Livewire concern used to own, because the gate has to answer outside any component and a second copy of its email fallback is how the two would drift apart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:20:21 +02:00
nexxo	ea643b5e73	Prove a custom domain before serving it, and keep proving it ... Two things. ── The update screen, still opening twice ─────────────────────────────────── Reported again on 1.3.9, and the cause was not the one fixed in 1.3.8. The agent consumes the request file BEFORE it resolves the release — deliberately, because update.sh may kill the shell and a request left in place would loop — and writes `state: running` only once it has decided to go ahead. In between, the request is gone and the status does not say running yet, so the endpoint honestly answers "nothing is running". The watcher read that as "the run has finished" and reloaded the page: overlay on the click, gone a poll later, 503 after it. The overlay now closes only once the server has BOTH confirmed a run and then stopped reporting it. Before the confirmation, silence means the agent has not got there yet. Bounded at twenty polls so a request the agent refuses does not leave the console covered forever. ── Custom domains, proven and re-proven ───────────────────────────────────── `custom_domain` was a free-text field and everything downstream believed it: the proxy served it, the certificate was issued for it, Nextcloud trusted it. Anyone who pointed any hostname at the platform got somebody else's files under their own name. The proof is a TXT record at _clupilot-challenge.<domain> holding a token only this instance has. Nothing is served until it has been read. Every reader now goes through Instance::address(), which is the one place the decision is made — `custom_domain ?: subdomain` was the hole, written out four times. It is re-read every night at 03:40, because a token checked once can be taken straight back out and a domain that later lapses keeps resolving here. Three consecutive misses before a live domain is withdrawn: one failed lookup is a nameserver having a bad minute, and withdrawing takes a working Nextcloud off its own address. The domain and its token stay on the row so the customer can put the record back rather than start over. Changing the domain mints a NEW token. Reusing it would let somebody who once verified example.com claim any other domain later without touching its DNS — the old record is still sitting there and only the value is compared. The domain is changeable at any time, and removable. Fixing it once set was considered and rejected: adding or moving an address is a proxy entry, a certificate and one line in trusted_domains. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:47:51 +02:00