Your first Cloudflare worker
Tags: cloudflare, workers, serverless, auth
Published: 2021-09-30 11:53:35

This post is a quick introduction to creating a Cloudflare worker. The worker it's self is a way to feel out the platform and a stepping stone to a more thorough worker that I'll be putting together to protect staging environment without having to resort to IP Address whitelisting to stop unauthorized users from accessing it and search engines from indexing it. 

Let's start at the start.

# What is a Cloudflare worker

Workers are Cloudflare's edge computing platform.  This allows us to run code within Cloudflare's data centres rather than having to do all processing at the origin server. 

## Why would I want  a cloudflare worker

Cloudflare workers operate on the request at the edge of the Cloudflare network. Here they can intercept, reject, redirect. modify or respond to a request. This can have a range of benefits including:  

- Faster response time when responding from the edge.
- Modify the request before it hits an origin server, injecting additional data that can be used by the origin server to validate requests or serve them from their correct location.
- Filter out requests that shouldn't be allowed through to the origin server.

Lets have a look at how to create a small worker with JavaScript that rejects a request when a certain cookie is not set on the browser and allows it through to the origin server when the cookie is there. 

## How do I create one

The simplest place to get started creating your first Cloudflare worker is by using the Cloudflare console. 

Once you've logged in open the workers page from the top menu. 

![Cloudflare navigation bar with workers highlighted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jcxify3i4sbwvmjjpoh0.png)

Select Manage workers to view/add/edit/delete your Cloudflare workers. 

![Screenshot of the Cloudflare workers page with Manage Workers highlighted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r28xvlfzlpjin3bqfcz1.png)

In the manage workers page select create a worker to make a new worker

![Screenshot of the manage workers page with Create a worker button highlighted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eixa0mp68wyg7grhvoil.png)

Now add the code. This sample code will check if there is a `__gateway_auth` cookie present on the request. If it is there it will transparently pass the request through to the origin and return the value. The code in the screenshot below can be found in [this gist.](https://www.notion.so/33ff4f60c51ea345ab5a213b974fb227) 

![A screenshot of the workers code editor with sample code](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p5jrfw5z7w9y4ekltuhq.png)

Save the worker code and navigate back to the domain that you want to add the worker into.  I'm going to use my `[saladsimulator.com](http://saladsimulator.com)` joke website. 

![Screenshot of the Cloudflare navigation panel with a link to saladsimulator.com domain highlighted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ltta6jpbx8synrqj4tl.png)

Select Add route to open the dialogue

![Screenshot of the workers page with Add Route highlighted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h4av8znsaljj0bck3mxk.png)

Add the worker on a route on your domain so that it's executed when a request is made on that path.  For this example I'm adding the worker to all calls to the `foo.saladsimulator.com` subdomain which doesn't exist.

![Screenshot of the add route page showing adding my-worker to foo.saladsimulator.com](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hy8t8hdycbx2zl6m2vi3.png)
![Screen shot showing my-worker applied to foo.saladsimulator.com](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3e5f2cmxh0o9c3xse2et.png)

Now we can navigate to our domain and we'll see the message that we set up for when no cookie is present.  


![A screenshot showing the worker blocking access to foo.saladsimulator.com because of a missing cookie](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t0n3y9y2rq9ceezc8a3w.png)

If you add the cookie you'll get a 404 response because there is nothing listening on that sub domain. 

# What's next.

So this is a fairly contrived example. It doesn't add any real security to the route. It is however a step towards what I am to build. I'd like to have a set up that protects a staging domain using authentication provided by Auth0. Typically I've found that staging environments are protected using IP address allow listing and I just don't think that's good enough in 2021. I want everything to be zero trust.