mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-22 23:42:16 +00:00
## Todos for release - [x] Configure Env in docs project on vercel - [x] Configure Root Path in the docs project on vercel - [ ] Remove old CSP https://github.com/zitadel/website/pull/1592 ## What we did This pull request migrates the project documentation from the old `docs/` directory to the new `apps/docs/` directory, introduces a new documentation system built with Next.js and Fumadocs, and updates all relevant references, configuration files, and documentation to reflect this change. It also adds new configuration and ignore files for the new documentation app, updates CI and linting to exclude the new docs from certain checks, and revises the contributing guidelines accordingly. **Documentation System Migration and New Docs App** * Migrated all documentation from `docs/` to `apps/docs/`, and updated all references in `README.md`, `CONTRIBUTING.md`, and other files to point to the new location. [[1]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L585-L640) [[2]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L660-R607) [[3]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L740-R687) [[4]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L2-R3) [[5]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L30-R30) * Added a new Next.js/Fumadocs-based documentation app under `apps/docs/`, including core app files, layouts, routing, search API, and a comprehensive `README.md` with development and contribution instructions. [[1]](diffhunk://#diff-5a1b07344a2c1b4d3f37b23ff1388b62cd9f57dea3c1cd23d8a0412b7602b132R1-R74) [[2]](diffhunk://#diff-462b9ad1eabbb7d1c29bb9c36e4931eb180fd7190900e6d2babf8f4d66ad1c28R1-R39) [[3]](diffhunk://#diff-e16ae25660ded787b10ac35dea96d5ecaacf895dae0afc8a9bd4382dc79a8c87R1-R7) [apps/docs/app/[[...slug]]/layout.tsxR1-R81](diffhunk://#diff-59e08acde4e805b7aeccef1dcf98f1d71dfc550777e6b9402085cee0e9fa4e0aR1-R81), [apps/docs/app/[[...slug]]/page.tsxR1-R79](diffhunk://#diff-e5df3f80d0fa01e12d63d81f29c57a9d14e846c78fd3beabb2ef768e38fd9580R1-R79), [[4]](diffhunk://#diff-389b34918e040cacaa87cd7201ffa462cc2b0b716736f537e3d3c660ac69353bR1-R7) [[5]](diffhunk://#diff-d3b03416d1c457b19f1c27b26f2db741412df841b875c26ccadc36e4522247f4R1-R29) [[6]](diffhunk://#diff-c8fb8339570a5305809be7c618e14705fd86390dc278e6ce8ba224a7bc8b0c3cR1-R25) **Configuration and Tooling Updates** * Updated `.github/workflows/codeql.yml`, `.golangci.yaml`, and `.github/dependabot.yml` to properly handle the new docs app: excluded `apps/docs` from certain checks, added npm dependency updates for the docs app, and excluded generated content. [[1]](diffhunk://#diff-12783128521e452af0cfac94b99b8d250413c516ec71fe6d97dbea666ff7ba27L8-R14) [[2]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R5-R6) [[3]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R126-R129) [[4]](diffhunk://#diff-dd4fbda47e51f1e35defb9275a9cd9c212ecde0b870cba89ddaaae65c5f3cd28R89-R106) * Updated `.devcontainer/devcontainer.json` to use the latest Go 1.25.3 version for consistency. **Licensing and Miscellaneous** * Added `apps/docs/` to the list of licensed directories in `LICENSING.md`. These changes ensure the documentation is now maintained in a modern, scalable system and all project tooling is updated to support the new structure. --------- Co-authored-by: Federico Coppede <[email protected]>
173 lines
5.1 KiB
Plaintext
173 lines
5.1 KiB
Plaintext
---
|
||
title: Testing Actions V2 with Webhook.site
|
||
sidebar_label: Testing Actions V2 with Webhook.site
|
||
---
|
||
|
||
## 1. Introduction
|
||
|
||
This guide explains how to test **ZITADEL Actions V2** locally using [Webhook.site](https://webhook.site).
|
||
We will use Webhook.site’s **XHR Redirect** feature to forward requests from ZITADEL to your local machine.
|
||
|
||
**What you will learn in this guide:**
|
||
|
||
- How to add the required CORS headers to your local listener
|
||
- How to configure Webhook.site with XHR Redirect
|
||
- How to create a target in ZITADEL and link it to your Action
|
||
- How to verify forwarded requests in your terminal
|
||
|
||
---
|
||
|
||
## 2. Prerequisites
|
||
|
||
### 2.1. Local Listener
|
||
|
||
You should already have a local HTTP server (for example, the Go example listener from [Testing a Request](./testing-request)) running at `http://localhost:8090/webhook`.
|
||
|
||
### 2.2. CORS Headers
|
||
|
||
Because Webhook.site’s XHR redirect runs in your browser, your listener must allow CORS.
|
||
Add the following headers in your handler:
|
||
|
||
```go
|
||
w.Header().Set("Access-Control-Allow-Origin", "*")
|
||
w.Header().Set("Access-Control-Allow-Methods", "*")
|
||
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
|
||
|
||
if req.Method == http.MethodOptions {
|
||
w.WriteHeader(http.StatusOK)
|
||
return
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Configure Webhook.site XHR Redirect
|
||
|
||
1. Open your unique Webhook.site URL.
|
||
2. Click **Configure XHR Redirect**.
|
||
3. Enable **XHR Redirect**.
|
||
4. Enter your local endpoint in **Target**, e.g.:
|
||
|
||
```
|
||
http://localhost:8090/webhook
|
||
```
|
||
|
||
5. Leave other fields empty unless you need custom headers.
|
||
6. Keep the Webhook.site browser tab open while testing.
|
||
|
||
<img src="/docs/img/actions-v2/webhook-xhr.png" alt="Screenshot: Webhook.site XHR Redirect configuration interface"/>
|
||
|
||
---
|
||
|
||
## 4. Run Your Listener
|
||
|
||
Start your local listener:
|
||
|
||
```sh
|
||
go run actionsRequest.go
|
||
```
|
||
|
||
You should see output in your console whenever the listener is called.
|
||
|
||
<img src="/docs/img/actions-v2/console.png" alt="Screenshot: Console output showing listener receiving webhook requests"/>
|
||
|
||
---
|
||
|
||
## 5. Create Target in ZITADEL
|
||
|
||
As shown in the example above, the target is created with HTTP and port '8090'. If you want to use it as a webhook, the target can be created as follows:
|
||
|
||
See [Create a target](/reference/api/action/zitadel.action.v2.ActionService.CreateTarget) for more detailed information. Notice that the `endpoint` is your Webhook.site URL.
|
||
|
||
```shell
|
||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
|
||
-H 'Content-Type: application/json' \
|
||
-H 'Accept: application/json' \
|
||
-H 'Authorization: Bearer <TOKEN>' \
|
||
--data-raw '{
|
||
"name": "local webhook",
|
||
"restWebhook": {
|
||
"interruptOnError": true
|
||
},
|
||
"endpoint": "https://webhook.site/29fa2769-e2f6-44ff-8eb0-2434b83507d8/webhook",
|
||
"timeout": "10s"
|
||
}'
|
||
```
|
||
|
||
<img src="/docs/img/actions-v2/webhook-url.png" alt="Screenshot: Webhook.site target creation interface"/>
|
||
|
||
---
|
||
|
||
Save the returned ID to use in the execution step. A sample response looks like this:
|
||
|
||
```json
|
||
{
|
||
"id": "337246363446151234",
|
||
"creationDate": "2025-09-10T13:21:36.959699Z",
|
||
"signingKey": "OpUHaCtEqh8swdJ5xUYbQ2bhej1abcXYZ"
|
||
}
|
||
```
|
||
|
||
## 6. Set execution
|
||
|
||
To configure ZITADEL to call the target when an API endpoint is called, set an execution and define the request condition.
|
||
|
||
See [Set an execution](/reference/api/action/zitadel.action.v2.ActionService.SetExecution) for more detailed information.
|
||
|
||
Here, `<TargetID returned>` is the `id` from the previous step.
|
||
|
||
```shell
|
||
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||
-H 'Content-Type: application/json' \
|
||
-H 'Accept: application/json' \
|
||
-H 'Authorization: Bearer <TOKEN>' \
|
||
--data-raw '{
|
||
"condition": {
|
||
"request": {
|
||
"method": "/zitadel.user.v2.UserService/AddHumanUser"
|
||
}
|
||
},
|
||
"targets": [
|
||
"<TargetID returned>"
|
||
]
|
||
}'
|
||
```
|
||
|
||
---
|
||
|
||
## 7. Example Call
|
||
|
||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or by calling the ZITADEL API to create a human user.
|
||
|
||
Here, we are creating a user via the API:
|
||
|
||
```shell
|
||
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/users/human' \
|
||
-H 'Content-Type: application/json' \
|
||
-H 'Accept: application/json' \
|
||
-H 'Authorization: Bearer <TOKEN>' \
|
||
--data-raw '{
|
||
"profile": {
|
||
"givenName": "Example_given",
|
||
"familyName": "Example_family"
|
||
},
|
||
"email": {
|
||
"email": "[email protected]"
|
||
}
|
||
}'
|
||
```
|
||
|
||
Both your Webhook.site and your local listener should now print out something like the following. See the [Sent information Request](./usage#sent-information-request) payload description for details.
|
||
|
||
Your local listener should look like this:
|
||
<img src="/docs/img/actions-v2/local-listener.png" alt="Screenshot: Local listener output"/>
|
||
|
||
Your Webhook.site should look like this:
|
||
<img src="/docs/img/actions-v2/webhook-listener.png" alt="Screenshot: Webhook.site request log"/>
|
||
|
||
---
|
||
|
||
## 8. Done
|
||
|
||
You now have a fully working setup for testing ZITADEL Actions V2 with Webhook.site. This allows you to forward requests securely from ZITADEL to your local environment without needing a public IP address or domain.
|