Change the secrets bound to a computer
Replaces the whole list; [] removes every binding. Each secret is resolved in the computer's own scope, as at create, and recorded at its LATEST revision — unless the entry names the revision_id it holds now, which keeps that one. Every start and restart delivers the latest value of each bound secret and moves its revision_id to it, so a replaced value needs at most a restart — one bound as a file, or as an environment variable on an image that supports it, is also sent to a running computer when it is replaced (see PUT /secrets/{id}), and moves revision_id once that lands. A binding says what was last delivered to the computer — or, until anything has been, the revision it was bound at — not what it is held to.
THE NEW VALUES ARRIVE AT THE NEXT START OR RESTART. A running computer keeps the environment it was started with until then, and a suspended one resumes holding the values it had when it was suspended. On an image that supports it, what starts AFTER the change is the exception: new shells and every exec on a running computer — plain or with session: "desktop" — see the new environment variables within seconds, with a removed one unset, while programs already running keep what they started with until the restart. A file newly bound or renamed waits for the restart either way. Restoring an older memory snapshot brings back that snapshot's values until the next reboot. A running computer whose change drops a secret or moves one to another revision cannot be suspended or memory-snapshotted until it restarts, because its memory may still hold the old value. Binding a computer for the first time needs a Linux template whose image can receive secrets, as create does, and the computer STOPPED: one started without secrets cannot receive them until it starts again, and a restart does not do that. 409 while it is running or suspended.
Send the version a read answered to change only the list you read: 409 if it has changed since. It answers 409 as well while a delivery is still in progress, and for a list that no longer binds, as a file, the secret the computer’s browser_proxy.credentials_secret_id names. It can also answer 409 during another operation, such as a stop, snapshot or suspend; retry once that operation finishes.
A nonempty list answers 409 while a workspace change is pending or the recorded binding scope disagrees with the computer’s current workspace. Before dispatch, a workspace change after binding resolution answers 409 if the computer remains visible to you; a scoped credential that loses access gets 404. An already accepted request can still answer 409 if the workspace changes while its reply is pending, even if that credential has lost access. Check the workspace change in the dashboard. For conflicting bindings, removing the entire list with {"secrets":[]} remains available wherever binding secrets is switched on (where it is not, every change to the list is a 400); omit version if reading the list answers 409. Then check any pending workspace change again before binding secrets in the current workspace.
Requires the member role or higher.
Request
- Base URL: https://app.mandala.computer/api/v1
- URL: https://app.mandala.computer/api/v1/computers/{id}/secrets
- Auth: HTTP bearer
Path parameters
The computer id.
Request body
Response
The bindings as they now are.
Changes
No recorded changes to this operation across all 1 revision of this API.