You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Worker validates this header on `/webhook` requests if the `WEBHOOK_SECRET` environment variable is set. If it's not set, the webhook accepts all valid payloads (the default behavior).
254
254
255
+
### Optional: Rate Limiting the Webhook Endpoint
256
+
257
+
The `/webhook` endpoint is open to the internet so devices can POST enrollment events. To prevent abuse (flooding with fake events, exhausting KV storage), you can add a Cloudflare WAF rate limiting rule. This is configured entirely in the Cloudflare dashboard — no code changes required.
258
+
259
+
#### Setup
260
+
261
+
1. In the [Cloudflare dashboard](https://dash.cloudflare.com), select your account and domain (or Workers route)
262
+
2. Go to **Security → WAF → Rate limiting rules**
263
+
3. Click **Create rule** and configure:
264
+
-**Rule name:**`Rate limit webhook`
265
+
-**If incoming requests match:** Field `URI Path` — Operator `equals` — Value `/webhook`
266
+
-**Rate:**`30 requests` per `1 minute` (adjust based on your fleet size)
267
+
-**With the same:**`IP Address`
268
+
-**Then:**`Block` for `1 minute`
269
+
4. Deploy the rule
270
+
271
+
#### Choosing the Right Rate
272
+
273
+
The rate depends on how many devices enroll simultaneously from the same IP. Each device sends exactly two webhook requests per enrollment (one `started`, one `finished`), so:
274
+
275
+
| Fleet scenario | Concurrent enrollments from one IP | Suggested rate |
| Medium site (10–50 devices) | 10–50 | 120 req/min |
279
+
| Large deployment (50+ from one NAT IP) | 50+ | 300 req/min |
280
+
281
+
If your devices enroll behind a shared NAT or VPN gateway, choose a higher limit to avoid blocking legitimate traffic. You can always start with a permissive limit and tighten it after observing real traffic patterns in **Security → Analytics**.
282
+
255
283
### Access Configuration Summary
256
284
257
285
| Route | Authentication | Who |
@@ -277,6 +305,43 @@ For local Worker development, create a `.dev.vars` file (see `.dev.vars.example`
277
305
278
306
> **Note:** Cloudflare Access is not active during local development. The dashboard is unprotected when running locally - this is expected and convenient for development.
279
307
308
+
## Testing the Dashboard
309
+
310
+
After deploying, you can populate the dashboard with dummy data to verify everything is working.
311
+
312
+
### Send Dummy Events
313
+
314
+
The included test script generates 140 realistic webhook events (70 started + 70 finished) across 10 simulated devices, spread over the past 3 days. This gives the dashboard enough data to display KPIs, charts, and event details.
Once the script finishes, open the dashboard in your browser. You should see events appearing with device details, enrollment actions, and charts populated with data.
331
+
332
+
### Cleaning Up Test Data from KV
333
+
334
+
After testing, you'll likely want to remove the dummy events. Cloudflare KV entries have a 90-day TTL so they will expire on their own, but you can remove them immediately through the Cloudflare dashboard:
335
+
336
+
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com)
337
+
2. Go to **Workers & Pages → KV** in the left sidebar
338
+
3. Click on your **WEBHOOKS** namespace
339
+
4. You'll see a list of stored keys — dummy events use serial numbers starting with `DUMMY` (e.g. `com.jamf.setupmanager.started:DUMMY000001:...`)
340
+
5. To delete individual entries: click the **three-dot menu** next to an entry and select **Delete**
341
+
6. To bulk delete all test data: select entries using the checkboxes, then click **Delete selected**
342
+
343
+
> **Tip:** You can use the search/filter field at the top of the KV viewer to filter keys containing `DUMMY` to quickly find and select all test entries.
0 commit comments