From fc8fdf5c3fad1b9eb1cdc6eaaabfbcd42c323833 Mon Sep 17 00:00:00 2001 From: WanYixian Date: Mon, 9 Dec 2024 11:29:54 +0800 Subject: [PATCH] minor update --- integrations/sources/eventbridge-webhook.mdx | 5 ++--- integrations/sources/hubspot-webhook.mdx | 6 +++--- integrations/sources/rudderstack-webhook.mdx | 8 ++++---- integrations/sources/segment-webhook.mdx | 15 +++++++-------- integrations/sources/webhook.mdx | 16 ++++++++-------- 5 files changed, 24 insertions(+), 26 deletions(-) diff --git a/integrations/sources/eventbridge-webhook.mdx b/integrations/sources/eventbridge-webhook.mdx index 11434e3e..28917631 100644 --- a/integrations/sources/eventbridge-webhook.mdx +++ b/integrations/sources/eventbridge-webhook.mdx @@ -41,7 +41,7 @@ create table wbhtable ( | :--------- | :-----------| | `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. | | `headers->>'...'` | Extracts the signature provided by Amazon EventBridge in the `authorization` HTTP header. The header key can be any string value and you can specify it when you create your webhook destination for RisingWave.

In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. | -| test_secret | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. | +| `test_secret` | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. | | `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. | ## 3. Set up webhook in Amazon EventBridge @@ -81,8 +81,7 @@ Sign in to the AWS Management Console and navigate to **Amazon EventBridge**. Create or Select an Event Bus: - In the EventBridge console, go to **Event buses**. -- You can use the default event bus or create a new custom event bus. - - To create a new event bus, click **Create event bus**, provide a name, and click **Create**. +- You can use the default event bus or create a new custom event bus. To create a new event bus, click **Create event bus**, provide a name, and click **Create**. Create a Rule for the Event Bus: diff --git a/integrations/sources/hubspot-webhook.mdx b/integrations/sources/hubspot-webhook.mdx index d76c72c1..f233332c 100644 --- a/integrations/sources/hubspot-webhook.mdx +++ b/integrations/sources/hubspot-webhook.mdx @@ -6,7 +6,7 @@ sidebarTitle: HubSpot webhook HubSpot is a CRM platform that provides various marketing, sales, and customer service features. It allows you to leverage webhooks through its workflow automation features. With these webhooks, you can receive real-time HTTP POST requests whenever specific events occur—such as a contact filling out a form or a deal reaching a certain stage—and forward that data to other systems. For example, you can automatically post a contact’s information to another CRM once they complete a form submission, or send deal details to an external shipment-handling system to initiate a purchase order. By integrating these HubSpot webhooks with RisingWave, you gain the ability to ingest and process this event data within your database, enabling real-time analytics and deeper insights into user behavior and engagement. -HubSpot Webhooks are not available on all HubSpot plans. You must have the appropriate subscription level (e.g., certain Operations Hub Enterprise plans) to access HubSpot Webhook functionality. Check your HubSpot plan details before proceeding. +HubSpot webhooks are not available on all HubSpot plans. You must have the appropriate subscription level (e.g., certain Operations Hub Enterprise plans) to access HubSpot Webhook functionality. Check your HubSpot plan details before proceeding. This guide will walk through the steps to set up RisingWave as a destination for HubSpot webhooks. @@ -50,7 +50,7 @@ CREATE TABLE wbhtable ( | :--------- | :-----------| | `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. | | `headers->>'...'` | Extracts the signature provided by HubSpot in the `x-hubspot-signature` HTTP header.

In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. | -| encode(...)` | Computes the expected signature by concatenating the secret, HTTP method (`POST`), RisingWave Webhook URL (`http://127.0.0.1:4560/webhook/dev/public/` in this example), and the request body converted from UTF-8 `data`. It then takes a `SHA-256` hash of this string and encodes it in hex. | +| `encode(...)` | Computes the expected signature by concatenating the secret, HTTP method (`POST`), RisingWave Webhook URL (`http://127.0.0.1:4560/webhook/dev/public/` in this example), and the request body converted from UTF-8 `data`. It then takes a `SHA-256` hash of this string and encodes it in hex. | | `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. | In HubSpot Webhook, several request validation methods are available, including v1, v2, v3, and API Key–based authentication. Each version employs a different approach to generating and verifying signatures, and may store the signature in a distinct header field. The SQL example above illustrates how to validate a signature generated using the v2 method. @@ -71,7 +71,7 @@ https:///webhook/// | Parameter | Description | |-----------|-------------| | `HOST` | The hostname or IP address where your RisingWave instance is accessible. This could be a domain name or an IP address. | -| `database` | The name of the RisingWave database where your table resides | +| `database` | The name of the RisingWave database where your table resides. | | `schema_name` | The schema name of your table, typically `public` unless specified otherwise. | | `table_name` | The name of the table you created to receive webhook data, e.g., `wbhtable`. | diff --git a/integrations/sources/rudderstack-webhook.mdx b/integrations/sources/rudderstack-webhook.mdx index 480b3489..6245e625 100644 --- a/integrations/sources/rudderstack-webhook.mdx +++ b/integrations/sources/rudderstack-webhook.mdx @@ -40,7 +40,7 @@ create table wbhtable ( | :--------- | :-----------| | `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. | | `headers->>'...'` | Extracts the signature provided by RudderStack in the `authorization` HTTP header. The header key can be any string value and you can specify it when you create your webhook destination for RisingWave.

In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. | -| test_secret | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. | +| `test_secret` | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. | | `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. | ## 3. Set up webhook in RudderStack @@ -72,7 +72,7 @@ Access RudderStack Dashboard: Log in to your RudderStack dashboard. As a CDP, RudderStack allow your build your own data pipeline. To sink data into RisingWave, you first need to have data sources. You can build your sources following the [guidance](https://www.rudderstack.com/docs/sources/overview/). -Upon you have created your source, in the left sidebar, click on **Collect** > **Destinations** > **New Destination**. +After creating your source, in the left sidebar, click on **Collect** > **Destinations** > **New Destination**. Choose Webhook as the Destination: @@ -86,8 +86,8 @@ Configure the webhook settings: - **Webhook URL**: Enter your RisingWave webhook URL. - **URL Method**: Select `POST`. - **Headers**: Keep the `content-type: application/json` unchanged. Add an `Authorization` header with the value set to your secret string ('TEST_WEBHOOK' or the secure string you used when creating `test_secret` in RisingWave). - - - Header Key: 'Authorization' (Or replace with the value you like, make sure it's aligned with the `CREATE TABLE` DML SQL) - - - Header Value: 'TEST_WEBHOOK' (replace with your actual secret) + - Header Key: `Authorization` (Or replace with the value you like, make sure it's aligned with the `CREATE TABLE` DML SQL). + - Header Value: `TEST_WEBHOOK` (replace with your actual secret). Save and Activate the Destination: diff --git a/integrations/sources/segment-webhook.mdx b/integrations/sources/segment-webhook.mdx index 41b25bad..005e3fb9 100644 --- a/integrations/sources/segment-webhook.mdx +++ b/integrations/sources/segment-webhook.mdx @@ -41,7 +41,7 @@ CREATE TABLE wbhtable ( | :--------- | :-----------| | `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. | | `headers->>'...'` | Extracts the signature provided by Segment in the `x-signature` HTTP header.

In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. | -| encode(...)` | Computes the expected signature. In the example above, it generates an `HMAC SHA-1` hash of the payload (`data`) using the secret (`test_secret`), encodes it in hexadecimal. | +| `encode(...)` | Computes the expected signature. In the example above, it generates an `HMAC SHA-1` hash of the payload (`data`) using the secret (`test_secret`), encodes it in hexadecimal. | | `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. | @@ -76,19 +76,18 @@ Log in to your Segment workspace. In the left sidebar, click on **Connections** > **Add Destination**. - Search for `webhook` in the list of available destinations. -- Select **Webhooks (Actions)** and click **Add destination** to proceed to configure it. +- Select **Webhooks (Actions)** and click **Add destination** to proceed. -- Select data source, which identify the source you want to send events from and follow the steps to name your destination. -- On the **Settings** > **Basic Settings** > **Shared Secret** tab: Enter the same secret string you used when creating the RisingWave -- secret (e.g., `'TEST_WEBHOOK'`). This ensures that Segment signs the payloads using this secret, allowing RisingWave to validate them. -- Check the **Settings** > **Basic Settings** > **Enable Destination** tab and ensure it's enabled. +- Select the data source that identifies the source you want to send events from and follow the steps to name your destination. +- Click on the tab **Settings** > **Basic Settings** > **Shared Secret**, enter the same secret string you used when creating the RisingWave secret (e.g., `'TEST_WEBHOOK'`). This ensures that Segment signs the payloads using this secret, allowing RisingWave to validate them. +- Click on the tab **Settings** > **Basic Settings** > **Enable Destination** and make sure it is enabled. Configure the webhook description on the **Mappings** tab. - Click **New Mapping** and then **Send**. -- Choose the event type you want to send to RisingWave -- Fill the configuration for the webhook requests based on the source information. You can also directly fill the values, filling RisingWave webhook URL as `URL, `POST` as `Method`. +- Choose the event type you want to send to RisingWave. +- Fill the configuration for the webhook requests based on the source information. You can also directly fill the values, filling RisingWave webhook URL as `URL`, `POST` as `Method`. At the end of the page, you can send the test message via **Send test event**. Review your settings, click **Next** and specify a name. diff --git a/integrations/sources/webhook.mdx b/integrations/sources/webhook.mdx index 36f4f2f0..d18dca7a 100644 --- a/integrations/sources/webhook.mdx +++ b/integrations/sources/webhook.mdx @@ -1,7 +1,7 @@ --- title: "Ingest data from webhook" sidebarTitle: Overview -description: Describes how to ingest data from webhook to RisingWave +description: Describes how to ingest data from webhook to RisingWave. --- A webhook is a mechanism that enables real-time data transfer between applications by sending immediate notifications when specific events occur. Instead of continuously polling for updates, applications can receive data automatically, making it an efficient way to integrate with third-party services. @@ -57,10 +57,10 @@ RisingWave has been verified to work with the following webhook sources and auth |webhook source|Authentication methods| | :-- | :-- | |GitHub| SHA-1 HMAC, SHA-256 HMAC | -|Rudderstack| Bearer Token | |Segment| SHA-1 HMAC | -|AWS EventBridge| Bearer Token | |HubSpot| API Key, Signature V2 | +|AWS EventBridge| Bearer Token | +|Rudderstack| Bearer Token | While only the above sources have been thoroughly tested, RisingWave can support additional webhook sources and authentication methods. You can integrate other services using similar configurations. @@ -68,8 +68,8 @@ RisingWave has been verified to work with the following webhook sources and auth Step-by-step guide to help you set up and configure your webhook sources: -[Ingest from Github webhook](/integrations/sources/github-webhook) -[Ingest from Segment webhook](/integrations/sources/segment-webhook) -[Ingest from HubSpot webhook](/integrations/sources/hubspot-webhook) -[Ingest from Amazon EventBridge webhook](/integrations/sources/eventbridge-webhook) -[Ingest from RudderStack webhook](/integrations/sources/rudderstack-webhook) +- [Ingest from Github webhook](/integrations/sources/github-webhook) +- [Ingest from Segment webhook](/integrations/sources/segment-webhook) +- [Ingest from HubSpot webhook](/integrations/sources/hubspot-webhook) +- [Ingest from Amazon EventBridge webhook](/integrations/sources/eventbridge-webhook) +- [Ingest from RudderStack webhook](/integrations/sources/rudderstack-webhook)