Note though that this is specifically for the Workers runtime, and not the Workers Product. While you can configure the runtime to allow access to internal services, on Workers itself this should not be possible
If you have a worker with a route assigned to it, you can fetch it because its a public url. But if you dont have any public urls they its only requestable through bindings which you can kinda compare to being a VPC from a traditional perspective
Yeah, the worker I'm going to setup for sending these webhooks won't have any public routes so I'm not worried about incoming requests. In the past I would have used something like https://github.com/stripe/smokescreen but with the way the service bindings are separated it seems that's not a concern here
hey everyone i am wondering that once you create/ set up the website on cloudflare is there a possible way for you to like have a html source and you can out html in that source and it will implement to your website? thanks
Hello everyone I have a few endpoints in one of my CF workers. I want if someone hits /endpoint-A, I want to make an API call to the /endpoint-B. Is this possible to implement? I tried it too, but it returns me this error
not as far as I know. Can't even break it down per namespace. You'd probably be best looking at worker analytics of workers you know which are using KV, and the specific limit you are exceeding
I'll give a bit more context, I have a mobile application, who's backend is entirely serverless on workers.
Ideally I'm not expecting to go beyond the workers paid plan of 10$ for the first year, but still would like to be open to scaling. It is connected to my (api.*) subdomain
im not worried about authentication issues or such, but what I am worried about is someone pinging the server a million times and driving up my request counts
(I should mention it's my first time worrying about things like this so I might be missing something very obvious, please do just share resources if i have to do some reading)
You need to identify what could separate a real user from an unwanted bot/crawler. This is a bit more difficult, issuing to the fact you don't want to(and probably can't) spawn a captcha in response to an interaction. If your app only operates in certain regions, block all other regions. If your app is only to be used on client devices, block datacenter IPs.
An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators on behalf of a single administrative entity or domain, that presents a common and clearly defined routing policy to the Internet. Each AS is assigned an autonomous system number (ASN), for use in Borde...
Maybe? If you block a regional ISP, then there is probably going to be issues. If the endpoint you are protecting is only ever meant to be accessed by mobile devices, then it should be reasonably safe to block datacenter IPs
You could do that? The Personal Access Token specifically only works on Apple devices, but Turnstile as a whole should work on anything with a mondern/standard-ish browser