ea643b5e73
tests / pest (push) Failing after 8m17s
Details
tests / assets (push) Successful in 23s
Details
tests / release (push) Has been skipped
Details
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> |
||
|---|---|---|
| .. | ||
| admin.php | ||
| admin_incidents.php | ||
| admin_settings.php | ||
| auth.php | ||
| backups.php | ||
| billing.php | ||
| cloud.php | ||
| coming_soon.php | ||
| common.php | ||
| dashboard.php | ||
| datacenters.php | ||
| devices.php | ||
| domain.php | ||
| errors.php | ||
| finance.php | ||
| hosts.php | ||
| impersonate.php | ||
| instances.php | ||
| integrations.php | ||
| invoice.php | ||
| invoice_mail.php | ||
| invoices.php | ||
| invoices_admin.php | ||
| mail.php | ||
| mail_settings.php | ||
| maintenance.php | ||
| orders.php | ||
| plans.php | ||
| provisioning.php | ||
| secrets.php | ||
| sessions.php | ||
| settings.php | ||
| status.php | ||
| support.php | ||
| two_factor_setup.php | ||
| updating.php | ||
| users.php | ||
| verify_email.php | ||
| vpn.php | ||