95463230cb
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>
12 lines
493 B
Ruby
12 lines
493 B
Ruby
json.id resource.id
|
|
json.name resource.name
|
|
json.description resource.description
|
|
json.thumbnail resource.avatar_url
|
|
json.outgoing_url resource.outgoing_url unless resource.system_bot?
|
|
json.bot_type resource.bot_type
|
|
json.bot_config resource.bot_config
|
|
json.account_id resource.account_id
|
|
json.access_token resource.access_token if resource.access_token.present?
|
|
json.secret resource.secret if !resource.system_bot? && Current.account_user&.administrator?
|
|
json.system_bot resource.system_bot?
|