feat(bots): allow bots to fetch their own enabled features#18529
Open
ShapeShifter499 wants to merge 1 commit into
Open
feat(bots): allow bots to fetch their own enabled features#18529ShapeShifter499 wants to merge 1 commit into
ShapeShifter499 wants to merge 1 commit into
Conversation
Bots previously had no way to learn which features (webhook, response,
event, reaction) an administrator enabled for them: the bot-list
endpoint requires admin credentials, and probing does not work either,
because a disabled feature yields the same 401 as an invalid secret,
while disabled webhooks simply never deliver. This made it impossible
for a bot to adapt its behavior, e.g. only offering reaction-based
interactions when the reaction feature is actually enabled.
Add GET /bot/{token}/features, authenticated with the same shared-secret
HMAC scheme as the other bot endpoints. As GET requests have no body,
the signature is computed over the random seed alone, following the
recording-settings precedent in SignalingController. Signing empty
content also gives domain separation: the message and reaction endpoints
reject empty content before authenticating (the reaction endpoints now
enforce this explicitly), so a captured features-request signature can
not be replayed against them.
The bot lookup accepts any enabled bot of the conversation regardless
of its feature flags (Bot::FEATURE_NONE skips the filter), because the
flags describe what a bot may do, not whether it may authenticate. The
previously unreachable feature re-check inside the checksum loop was
removed, and the per-endpoint header reading and error/throttle handling
was extracted into a shared getBotOrErrorResponse() helper, with the
RequestHeader attributes marked indirect accordingly.
The new endpoint is announced via the bot-features-api capability,
documented in docs/bots.md and covered by a new integration test
scenario. OpenAPI specs and TypeScript types were regenerated.
Resolves: nextcloud#18523
Signed-off-by: Lance <Gero3977@gmail.com>
Assisted-by: Claude-Code:claude-fable-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
☑️ Resolves
AI (if applicable)
🛠️ Description
Adds
GET /bot/{token}/featuresso a bot can check which features an administrator enabled for it, authenticated with its own shared secret instead of admin credentials.Why polling instead of "try and report the error": a disabled feature is indistinguishable from a broken secret from the bot's side —
getBotsForToken()filters by feature before the checksum trial, so a response-disabled bot gets the same401as one with a wrong secret. Webhook delivery can't be probed at all; it just silently never happens. My concrete case: a bot that offers reaction-based interactions (e.g. approve/deny via ✅/❌) needs to know up front whether the reaction feature is enabled, rather than degrading mid-conversation.Design: the endpoint reuses the existing
X-Nextcloud-Talk-Bot-Random/X-Nextcloud-Talk-Bot-SignatureHMAC scheme. SinceGEThas no body, the signature is computed over the random seed alone — modeled after the recording-settings endpoint inSignalingController, which signs random-only for the same reason (the SIP bridge variant signs random+token, but the conversation is already bound via the URL token in the bot lookup). Signing empty content also gives domain separation: the message and reaction endpoints reject empty content before authenticating (the reaction endpoints now enforce this explicitly), so a captured features-request signature cannot be replayed to post a message or reaction.The bot lookup accepts any enabled bot of the conversation regardless of feature flags (
Bot::FEATURE_NONEskips the filter) — the flags describe what a bot may do, not whether it may authenticate; a state-disabled bot still gets401. Along the way the unreachable feature re-check inside the checksum loop was removed and the duplicated header/throttle handling was extracted into a sharedgetBotOrErrorResponse()helper.🛠️ API Checklist
🏁 Checklist
docs/has been updated or is not requiredSigned-off-by: Lance Gero3977@gmail.com
Assisted-by: Claude-Code:claude-fable-5