mirror of
https://github.com/mudler/LocalAI.git
synced 2026-11-06 04:23:15 -05:00
A binding with its capabilities ticked still gave nothing to the owner's own allowlisted account: Authorize wanted a pairing or a role even for capabilities that are not sensitive, so the agent had no reminder, memory or talk-back tool. A sender whose ID or @name is an entry of the allowlist now holds every capability that is not sensitive, within the ceiling of the binding and while no switch is off. The decision says Via "allowlist". A sensitive capability still needs a pairing, and a role never grants it. The entry of a channel or group lets its members talk to the bot but does not trust them: the trust is matched against the sender only, and a binding that accepts anyone lists nobody. Such a sender still gets capabilities from a pairing or a role. The capability gate takes the handle of the sender for the same match, and a sensitive request ignores the allowlist as it ignores roles. When a tool is held back for a missing right, the turn now carries a short note with the reason in plain words and tells the model to relay it, instead of saying that it has no such tool. The reasons are kept in the grant of the turn, so a worker reports the same words. The access view lists a "listed" sender apart from one let in through a channel. Assisted-by: Claude:claude-sonnet-5-5
42 lines
1.8 KiB
Go
42 lines
1.8 KiB
Go
package workerctl
|
|
|
|
// ChatStartRequest is the payload of a chat start: a frontend asks a chat
|
|
// worker to run the next turn of an unattended chat (a trigger run, a job or a
|
|
// connector message). The worker reads the chat, its owner and its model from
|
|
// the shared database, so the request names only the chat and the message.
|
|
type ChatStartRequest struct {
|
|
// Principal is the owner of the chat as the chats service names it.
|
|
Principal string `json:"principal"`
|
|
ChatID string `json:"chat_id"`
|
|
Text string `json:"text"`
|
|
// Grant is set for a connector message: what the sender of the turn may
|
|
// do. The worker keeps it for the turn, so a tool it builds is offered
|
|
// only for the capabilities in it. A start without a grant for a connector
|
|
// chat gets none of the gated tools.
|
|
Grant *ChatGrant `json:"grant,omitempty"`
|
|
}
|
|
|
|
// ChatGrant is the outcome of the permission check for the senders of one
|
|
// connector turn (see studio.Authorize). It holds IDs, never message text.
|
|
type ChatGrant struct {
|
|
Binding string `json:"binding"`
|
|
Kind string `json:"kind,omitempty"`
|
|
Senders []string `json:"senders,omitempty"`
|
|
Roles []string `json:"roles,omitempty"`
|
|
// Caps are the capabilities every sender of the turn holds.
|
|
Caps []string `json:"caps,omitempty"`
|
|
// Denied says why a capability in the ceiling is not held, by name.
|
|
Denied map[string]string `json:"denied,omitempty"`
|
|
}
|
|
|
|
// ChatStartReply is the worker's answer to a ChatStartRequest. With Error
|
|
// empty, Started says whether the message began a turn on the worker;
|
|
// otherwise a turn was running, and the message waits under PendingID. A
|
|
// non-empty Error is the worker's refusal: the worker is present, and nothing
|
|
// started.
|
|
type ChatStartReply struct {
|
|
Started bool `json:"started,omitempty"`
|
|
PendingID string `json:"pending_id,omitempty"`
|
|
Error string `json:"error,omitempty"`
|
|
}
|