This repository contains the Cloudflare Worker script for reverse proxying all the Finsweet subdomains under the main finsweet.com
domain, as well as documentation on how to properly manage them.
Contents:
Important!!
Before deploying new updates to the reverse proxy worker using pnpm run deploy
, make sure all the env variables in wrangler.toml
are in sync with the ones in the Cloudflare Worker dashboard.
This flowchart summarizes the internal logic of the reverse proxy:
The DNS of the finsweet.com
domain are managed from Cloudflare. You can access it by asking @alexiglesias to include you as a team member of the Cloudflare account.
In there, you will notice that some DNS records are set to be proxied, and some not. Continue reading to know the differences between them.
The main difference resides whether Cloudflare will intercept any request to the destination before it reaches it.
As a rule of thumb, only the reverse-proxied subdomains need to be proxied to intercept any request to them before it reaches Webflow's servers.
Any DNS that is set to point to a non-Webflow destination, like cdn.finsweet.com
should be set to DNS only
.
There are two reasons for this:
- How Webflow generates the SSL certificate to all the pointed domains.
- The requirements for an SSL Handshake to be valid.
When pointing a DNS record to proxy-ssl.webflow.com
, Webflow automatically creates an SSL certificate that is valid for 3 months, and auto-renews it when this period is coming to an end.
The problem comes when we proxy this DNS record, as it is no longer pointed directly to Webflow's servers, and instead it goes through Cloudflare first. This causes Webflow not being able to generate a valid SSL certificate.
The only solution to this problem is uploading custom SSL certificates to Webflow, which is currently something that is only offered to Enterprise customers.
An SSL Handshake requires both parties (Cloudflare and Webflow) to share an SSL certificate to determine that a connection is secure.
As this is not possible, we need to point the connection to the plain proxy.webflow.com
origin and rely on Cloudflare's Flexible mode to encrypt the connection between the browser and Cloudflare.
The process is split in the following steps:
- Correctly configuring the Webflow project.
- Creating the subdomain's DNS record.
- Adding the to-be-proxied subdomain to the Cloudflare Worker environment.
In the Hosting tab, set up the project domain as SUBDOMAIN_NAME.finsweet.com
. After the setup is done correctly, all the traffic will be served under finsweet.com/SUBDOMAIN_NAME
.
In the SEO tab, add https://finsweet.com/SUBDOMAIN_NAME
as the Global Canonical Tag URL (note the https://
in front of the domain, this is mandatory).
This will make sure Google doesn't consider any content outside of the finsweet.com
main domain to be duplicated.
In the Custom Code tab, add the same https://finsweet.com/SUBDOMAIN_NAME
URL as the Href Prefix.
This will assure that all relative URLs across the project point correctly to the reverse-proxied path instead of the original subdomain.
By default, Cloudflare adds a 4h cache to all the assets that are being reverse-proxied. This means that if you publish any changes to the Webflow project (the .webflow.io
staging domain is not cached, only the live SUBDOMAIN_NAME.finsweet.com
version), it can take up to 4h for users to see the new changes.
To prevent this, there's the option of immediately purging the cache whenever a Finsweet site is published.
To do so, move to the Integrations tab and create a Site Publish Webhook with the following URL:
https://api.finsweet.com/cache/purge
Easy step, you just need to move to the DNS tab in Cloudflare and click to + Add record
.
Enter the following settings:
- Type:
CNAME
. - Name: The
SUBDOMAIN_NAME
. - Target:
proxy.webflow.com
. - TTL: Auto.
- Proxy status: Proxied.
And Save it.
Last step, move to the Workers tab in Cloudflare and click on the reverse-proxy
worker.
In it, locate the Settings tab and click on Edit variables
.
In there, you will notice a SUBDOMAINS
variable that contains a comma-separated list of all the reverse-proxied subdomains. Add here the new subdomain, making sure that:
- The subdomain it's not repeated (it doesn't exist already in the list).
- You use a comma
,
to separate each subdomain. The white spaces don't matter and have no effect.
Hit on Save, and you're done! Don't forget to test it out 💪.
Webflow keeps track of the user's actions in e-commerce sites with cookies and CSRF tokens to prevent any sort of malicious behaviors.
Every time that an action is performed by the user (Adding an product to the cart, calculating the checkout value, filling the payment form, etc), Webflow makes a request to their servers and validates it. The problem comes when Webflow detects that the page where the user is acting is not the one that it's supposed to be (finsweet.com/SUBDOMAIN
instead of SUBDOMAIN.finsweet.com
) and blocks the action.
This is probably caused by Cloudflare's caching, read Purge cache on publish to learn how to bypass it.
Contact @alexiglesias and he will invite you to join the team.