Skip to content

Commit

Permalink
replace 'whitelist' with 'allowlist'
Browse files Browse the repository at this point in the history
  • Loading branch information
drakirnosslin committed Nov 13, 2023
1 parent 43fe3c8 commit 6362baa
Show file tree
Hide file tree
Showing 3 changed files with 11 additions and 11 deletions.
Original file line number Diff line number Diff line change
@@ -1,44 +1,44 @@
---
title: Whitelisting & filtering traffic
title: Allowlisting & filtering traffic
weight: 6
menu:
platform:
parent: "Monitoring"
---

There are cases in which you might have to whitelist Checkly traffic in your firewall, load balancer or other to prevent it from being blocked or skewing analytics data. Below are some solutions to help you achieve that.
There are cases in which you might have to allowlist Checkly traffic in your firewall, load balancer or other to prevent it from being blocked or skewing analytics data. Below are some solutions to help you achieve that.

## IP range whitelisting
## IP range allowlisting

Whitelisting Checkly traffic by IP address or range is not possible at this moment, as Checkly uses a non-static set of IP addresses in the cloud to run its checks.
Allowlisting Checkly traffic by IP address or range is not possible at this moment, as Checkly uses a non-static set of IP addresses in the cloud to run its checks.

You can however fetch a list of the [dynamic IP addresses](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) in use at AWS, our cloud provider.

{{<warning>}}
Since the AWS IP ranges are quite vast, we suggest trying one of the methods below instead.
{{</warning>}}

## Header/user agent whitelisting
## Header/user agent allowlisting

If you are using Cloudflare or a similar provider, one or more of your automated checks might trigger a [bot detection mechanism](https://www.cloudflare.com/learning/bots/what-is-bot-traffic/).

If you want to prevent that from happening without exposing your website to any and all automated traffic, you might want to set up a new [firewall rule](https://developers.cloudflare.com/firewall/cf-firewall-rules/) allowing traffic from Checkly as long as it contains a specific header or sets a certain user agent.

You can make the header and/or user agent specific to your own Checkly user account by grabbing the first eight digits of your unique user ID (or another fixed value of your choice), which you can find below your account name on the [Account Settings page](https://app.checklyhq.com/settings/account/). Embedding this value in your checks will enable them to be allowed through by your firewall rules.

### Whitelisting API checks using headers
### Allowlisting API checks using headers

To whitelist API checks, allow traffic that contains a cookie in the shape of `Cookie: "checkly-account:<UUID>"`, with `<UUID>` being your shortened Checkly ID or other chosen value.
To allowlist API checks, allow traffic that contains a cookie in the shape of `Cookie: "checkly-account:<UUID>"`, with `<UUID>` being your shortened Checkly ID or other chosen value.

You can then [set the Cookie header](https://checklyhq.com/docs/api-checks/request-settings/#headers) while editing your check.

{{<info>}}
You can set the header at group-level using [API check defaults](/docs/groups/api-check-defaults/#headers--query-parameters) to have it applied to every API check in the group.
{{</info>}}

### Whitelisting browser checks with user agents
### Allowlisting browser checks with user agents

To whitelist browser checks, allow traffic with user agent containing `Checkly/<UUID>`, with `<UUID>` being your shortened Checkly ID or another chosen value.
To allowlist browser checks, allow traffic with user agent containing `Checkly/<UUID>`, with `<UUID>` being your shortened Checkly ID or another chosen value.

You will then be able to set up the matching user agent in your browser checks using Playwright's [`userAgent`](https://playwright.dev/docs/emulation#user-agent) property.

Expand Down
2 changes: 1 addition & 1 deletion site/content/docs/monitoring/ip-info.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,4 +41,4 @@ Puppeteer-based browser checks do not support IPv6 and will not in the future as
We currently do not have a set of fixed, public IP ranges but are working on this. See and follow [our public roadmap item on static
IPs](https://checkly.featurebase.app/submissions/6464dc4c0f356460eca41435) for updates.

Note, if you are looking to whitelist Checkly traffic, [see our docs on whitelisting](/docs/monitoring/whitelisting/).
Note, if you are looking to allowlist Checkly traffic, [see our docs on allowlisting](/docs/monitoring/allowlisting/).
2 changes: 1 addition & 1 deletion site/content/guides/end-to-end-monitoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -278,4 +278,4 @@ We learned things the hard way so you do not have to. When starting out, keep an

* Long, unfocused tests: checking too much in a single test will make failures harder to debug. [Break it up instead](/learn/headless/valuable-tests/#keep-tests-focused), and enjoy the added parallelisation.

* Messing up your own metrics, KPIs: remember, if you are not running against production, you want to make sure your E2E monitoring checks or tests are filtered out of your analytics. This is [rather easy to do](https://www.checklyhq.com/docs/monitoring/whitelisting), with most headless browser tools normally identifying themselves as such from the start.
* Messing up your own metrics, KPIs: remember, if you are not running against production, you want to make sure your E2E monitoring checks or tests are filtered out of your analytics. This is [rather easy to do](/docs/monitoring/allowlisting), with most headless browser tools normally identifying themselves as such from the start.

0 comments on commit 6362baa

Please sign in to comment.