f0ec2fe03f
tests / pest (push) Failing after 7m22s
Details
tests / assets (push) Successful in 20s
Details
tests / release (push) Has been skipped
Details
The first version put it in the credential vault. The vault refuses it, and correctly: it keeps a registry of fixed, documented credentials so the Secrets page can describe each one, and a per-destination password is not that. Forcing a dynamic key into that registry would have made the registry meaningless. Encrypted onto the row with the same cipher instead — the same key, so it is no more readable in a database dump than anything the vault holds, and it lives with the record it describes. A rotated SECRETS_KEY now says so by name rather than surfacing as an authentication failure against a host that is perfectly fine. Also answers the question that prompted this: the host, port and user fields are there, and appear once SFTP is chosen. A mounted directory has no host on purpose — the mount is made on the server with mount(8), and the application only names the directory it writes into. A test asserts both halves, because "the fields are there, you just cannot see them yet" is not something anybody should have to take on trust. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Admin | ||
| Auth | ||
| Concerns | ||
| Backups.php | ||
| Billing.php | ||
| Cloud.php | ||
| ConfirmCancelPackage.php | ||
| ConfirmCloseAccount.php | ||
| ConfirmDisableTwoFactor.php | ||
| ConfirmEndOtherSessions.php | ||
| ConfirmRemoveOrder.php | ||
| ConfirmRevokeSeat.php | ||
| CustomerProvisioning.php | ||
| Dashboard.php | ||
| EditMailbox.php | ||
| EditSeat.php | ||
| Invoices.php | ||
| NewSupportRequest.php | ||
| Sessions.php | ||
| Settings.php | ||
| Support.php | ||
| Users.php | ||