feat:533 webhook secrets

[jchui-wd]

Adds opt-in secret-based authentication for webhook-triggered agentflows.
Is Tied to #6217

Changes

Backend

• New webhookSecret (hidden) and webhookSecretConfigured (boolean) columns on ChatFlow, with migrations for all 4 databases
• POST /chatflows/:id/webhook-secret and DELETE /chatflows/:id/webhook-secret to generate/remove secrets
• Signature verification runs before all other validation — supports HMAC-SHA256/SHA1 (GitHub, Stripe, Slack) and plain token (GitLab)

Start Node (v1.2)

• When webhookTrigger is selected, now shows a generate secrets section with signature header, and signature type.

UI

• webhookURL field renders the full trigger URL with a copy button
• webhookSecret field manages generate/regenerate/remove with the plaintext shown only immediately after generation, then masked on reload

Test Videos Demo

WrongSignatureType-Fail.mp4

WrongSignatureType-Fail.mp4

PlainToken-WrongHeaderName-Fail.mp4

PlainToken-WrongHeaderName-Fail.mp4

PlainToken-working.mp4

PlainToken-working.mp4

No-Secret-401.mp4

No-Secret-401.mp4

HMAC-non256-working.mp4

HMAC-non256-working.mp4

HMAC-256-working.mp4

HMAC-256-working.mp4

Screenshots

Signature Type

No Secrets Generated

Tests

[gemini-code-assist]

Code Review

This pull request enhances the webhook trigger functionality in Agentflows by adding support for HTTP method selection, Content-Type validation, and secure signature verification (HMAC-SHA256 and Plain Token). It introduces new configuration fields in the Start node, updates the database schema to store webhook secrets, and implements comprehensive validation logic in the backend. Additionally, the UI is updated to allow users to manage webhook secrets and access namespaced variables for headers, query parameters, and body content. Review feedback suggests refining the raw body storage type and improving type validation for form-encoded webhook payloads.

I am having trouble creating individual review comments. Click here to see my feedback.

packages/server/src/index.ts (168)

The buf provided by the verify callback of express.json and express.urlencoded is a Buffer. Casting it to a string using as unknown as string is misleading and potentially problematic if other parts of the application expect a string. Since verifyWebhookSignature correctly expects a Buffer, it is better to store it as such.

            ;(req as any).rawBody = buf

packages/server/src/services/webhook/index.ts (87-89)

The strict typeof check will fail for number and boolean types when the incoming request is application/x-www-form-urlencoded, as all values in the request body are parsed as strings by default. Consider adding logic to handle numeric strings and boolean strings (e.g., "true", "false") to improve compatibility with various webhook senders.

        const typeMismatch = webhookBodyParams
            .filter((p) => {
                if (p.type == null || body?.[p.name] == null) return false
                const val = body[p.name]
                if (p.type === 'number') return isNaN(Number(val))
                if (p.type === 'boolean') return typeof val !== 'boolean' && val !== 'true' && val !== 'false'
                return typeof val !== p.type
            })
            .map((p) => p.name)

[HenryHengZJ]

what do u think if we group these into a column like webhookConfig, similar to mcpServerConfig

[jchui-wd]

@HenryHengZJ

I can group webhookSecret and webhookSecretConfigured make it as a webhookConfig just like mcpServerConfig, but I separated them intentionally because I didn't want the webhookSecret to be exposed when a user does a api/chatflow call since the secret is stored 'as is'.

so I added select: false for webhookSecrets, but we still need to know if it is configured so the Start.node can render out the correct UI if there is already a secret hence webhookSecretConfigured.

Any thoughts on this?

I think I should also add webhookSecret and webhookSecretConfigured in stripProtectedFields.ts, but I'll hold off until we are aligned on this.

[henry-heng-wd]

i see it make sense, lets stick to this approach