feat: sign webhooks for API channel and agentbots (#13892)
Account webhooks sign outgoing payloads with HMAC-SHA256, but agent bot and API inbox webhooks were delivered unsigned. This PR adds the same signing to both. Each model gets a dedicated `secret` column rather than reusing the agent bot's `access_token` (for API auth back into Chatwoot) or the API inbox's `hmac_token` (for inbound contact identity verification). These serve different trust boundaries and shouldn't be coupled — rotating a signing secret shouldn't invalidate API access or contact verification. The existing `Webhooks::Trigger` already signs when a secret is present, so the backend change is just passing `secret:` through to the jobs. Shared token logic is extracted into a `WebhookSecretable` concern included by `Webhook`, `AgentBot`, and `Channel::Api`. The frontend reuses the existing `AccessToken` component for secret display. Secrets are admin-only and excluded from enterprise audit logs. ### How to test Point an agent bot or API inbox webhook URL at a request inspector. Send a message and verify `X-Chatwoot-Signature` and `X-Chatwoot-Timestamp` headers are present. Reset the secret from settings and confirm subsequent deliveries use the new value. --------- Co-authored-by: Sojan Jose <sojan@pepalo.com>
This commit is contained in:
@@ -7,6 +7,7 @@
|
||||
# hmac_mandatory :boolean default(FALSE)
|
||||
# hmac_token :string
|
||||
# identifier :string
|
||||
# secret :string
|
||||
# webhook_url :string
|
||||
# created_at :datetime not null
|
||||
# updated_at :datetime not null
|
||||
@@ -26,6 +27,7 @@ class Channel::Api < ApplicationRecord
|
||||
|
||||
has_secure_token :identifier
|
||||
has_secure_token :hmac_token
|
||||
include WebhookSecretable
|
||||
validate :ensure_valid_agent_reply_time_window
|
||||
validates :webhook_url, length: { maximum: Limits::URL_LENGTH_LIMIT }
|
||||
|
||||
|
||||
Reference in New Issue
Block a user