4.1 KiB
Purpose
Define how an authenticated Host Agent local Console submits Host-scoped goal tasks safely through the existing Cloud control-plane self-submission operation.
Requirements
Requirement: Authenticated local Console submits a Host-scoped goal task
The Host Agent local Console SHALL provide a task-submission form on its authenticated Tasks page. The form SHALL submit a non-empty goal through the existing Host Agent self-submission client operation, which remains scoped to the currently authenticated Host at the Cloud boundary.
The form SHALL offer an automatic-device option and the IDs of devices that are currently registered in the running DeviceManager. An automatic-device submission SHALL omit the device target so that the Cloud scheduler selects an eligible device owned by the Host. An explicit submission SHALL pass the selected runtime device ID unchanged; in enrollment-managed deployments this is the Cloud device ID, not the local configuration ID.
Scenario: Operator submits a task with automatic device selection
- WHEN an authenticated local Console operator submits a non-empty goal and leaves the device selection on automatic
- THEN the Console invokes the existing Host self-submission operation without a device target and the resulting task remains constrained to that Host
Scenario: Operator submits a task for a listed device
- WHEN an authenticated local Console operator selects a currently running device and submits a non-empty goal
- THEN the Console passes that runtime device ID to the Host self-submission operation without accepting a Host ID or workflow reference from the form
Requirement: Local task submission is protected and locally validated
The Console SHALL require its existing valid local session and CSRF token for every task-submission POST. It SHALL reject an empty goal or a selected device that is no longer present in the current DeviceManager snapshot before calling the Cloud client.
Scenario: Unauthenticated or CSRF-invalid request is rejected
- WHEN a task-submission POST has no valid local session or CSRF token
- THEN the Console rejects the request and does not invoke the Host self-submission client
Scenario: Stale device selection is rejected locally
- WHEN an operator submits a device ID that is absent from the current DeviceManager snapshot
- THEN the Console returns a validation error and does not enqueue a task
Requirement: Console acknowledges a confirmed submission safely
After the Host client confirms task creation, the Console SHALL use a post-redirect-get response to show the returned Cloud task ID and SHALL write a bounded local history entry containing the task ID and optional target device ID. The history entry SHALL NOT persist the task goal, Host credential, cookie, or lease secret.
Scenario: Confirmed task creation is acknowledged
- WHEN the Host self-submission operation returns a task ID
- THEN the Console redirects to the Tasks page with a visible confirmation and records a non-secret local submission audit entry
Scenario: Control plane rejects submission
- WHEN the Host self-submission operation returns a definitive rejection such as a disabled self-submission policy or invalid target
- THEN the Console renders a safe error to the operator and does not report a task ID or record a successful submission audit entry
Requirement: Non-idempotent task creation is attempted at most once
The Host Agent client SHALL not automatically retry a Host self-submission request after a transport failure, server error, or malformed success response. The Console SHALL report that such a submission has an unknown outcome and SHALL NOT claim that no task was created.
Scenario: Transport outcome is uncertain
- WHEN the task-submission request loses its response or receives a server failure after the request may have reached the control plane
- THEN the client makes no second creation request and the Console informs the operator that the task may have been queued and must be checked before submitting again