Hi there —
I have more of a sales related question, so I hope I will receive an answer anyways…
Here’s the scenario: We are currently planning a (at least for now) on-off marketing cooperation that will generate loads of clicks. Therefore we need some edge caches that takes the load off of our servers and autoscales at best. The cooperation works as follows: The user has a “deal” app that shows our deal for a limited amount of time. When the user clicks the deal a webpage opens and the user can leave his email address to receive a little present from us. This webpage is static, will be hosted on our servers and cached by Cloudflare. So far — easy.
Now comes the tricky bit: The partner we have the cooperation with wants us to only make the landing page available when it was opened through his app. To achieve that we agreed on the following (I know it is not super safe, but the partner agreed): The app should open a tokenized link that redirects to the actual landing page. The landing page itself will only work if the referring page was the one with the token (and be loaded from CF cache); otherwise it will show a 404.
Is this possible using Cloudflare? If so, what package and tools do I need to make something like this work?
For this, you’ll need either the BIZ or ENT plan and then request for the tokenization of your landing page to our support team. Basically, Cloudflare will provide the server-side verification and you’ll be required to implement the client-side logic so we can receive tokenized requests (encrypted with the shared key, optional expiration and the link itself)
I have a different implementation idea. What if, instead of a tokenized URL, they add a specific Header? Like X-Link-Source or similar. That header could then be checked, very easily, by a Worker (0.5$/10M queries) and then if present passed to the correct page, otherwise to a dead 404 version?
In this case the implementation is extremely simple and everything is kept within CF. With you option you would have every new link (if automatically generated per each access) MISS the cache and go to the origin, which does the decision and then redirects, reducing performance, increasing cost and user friendliness while allowing an attacker (or random user) the means to understand that something is there.
EDIT after seeing the response from Cloudflare: my option would work on a Free or Pro plan.
@matteo, you’re right at the exception that you can exclude the query strings from the cache key so this scenario still works with CF and this will be cached.
This can be done with WAF or a worker with the query string and Worker only if inserted in a request header.
Yeah, I forgot about the option in the settings/page rule… I guess it depends on the volume for them and specific requirements: custom nameservers (which would be lovely on lower plans as add-ons, but understand why they are not), custom SSL, etc. or volume above 400M requests a month.
Hi @stephane and @matteo — thank you both for our replies. Since I am really new to CF I try to understand what you are saying and have a couple of questions:
Generally we would want the users to keep off of our servers to a most possible extend. If we work with the tokenization we would have to validate the tokens on our infrastructure correct?
When using a service worker for checking token or header and the service worker evaluates the token to be valid, will the user then see the url of the landingpage in his addressbar? If so, than what would happen if you call open the url directly?
Can we setup a WAF custom rule to prevent access to a specific url when a criteria is not met (aka a header or url token is missing)? Unfortunately I haven’t found much information about the WAF personal rules. Do you have any resources on that?
I really don’t know here, never had a Business plan, @stephane will help you better.
Not necessarily, it depends if you redirect to the page or serve it instead of the current one (here should explain a little bit more, A/B testing with same-URL direct access · Cloudflare Workers docs, look at the documentation as @stephane indicated) but in the case of a header (or a token validated via worker) it would work only if present, otherwise it’s a 404 on the same page. For example: Example Domain and example.com point to the same page, but the worker would reply with a correct page in the first case and a 404 in the second.
EDIT: on mobile, otherwise I could put down a couple of lines of code.
Nope, the tokenization is done by your application, the validation is done in our EDGE (workers or WAF, that’s the same place)
That’s up to you, you can give the access to the page if the token is correct and rewrite the URL as well so the token isn’t shown, that will depend on your JS developer skills
If the token authentication is done with a WAF rule, we only allow connections made with a correct token, all the others will receive a 403. The WAF rule is applied to a specific portion of your application, in your example that will be your landingpage.
