I am testing an implementation to remove certain experience endpoints that are “attacked”, receive many requests, but I noticed that even when consuming an endpoint it was removed, the payload counter for API experience endpoints requests is increased. Is this behavior correct? It seems to me that for a given slug, regardless of whether an endpoint has been configured, the application receives the request.
Example:
I created an experience, with a slug pointing to a version that doesn’t have the / testing-route, and
this request appears in the application log, and I noticed that the application’s payload count was increased
You are correct that your Losant app will still receive requests even when endpoints are not defined. Losant will automatically reply with a 404 and will record the 404 in your experience’s metrics. These metrics can be useful if you’ve accidentally linked to an endpoint that doesn’t exist. Seeing 404s is an indicator something might be implemented incorrectly.
In your case, however, I can certainly see why you’d want to completely block these requests.
My first reaction is to use Cloudflare in front of your Losant experience. Cloudflare does have firewall rules that can block specific endpoints from ever reaching Losant. Here’s an example:
We don’t have a guide (yet) for using Cloudflare and Losant, but this is something I’d definitely recommend investigating yourself to see if it’s a possible solution.
This raises a vert good point in general - what API rate limiting or alerting tools are available to prevent DDoS style attacks causing great financial pain around Losant billable messages, and if they aren’t built-in, can Losant please create working Cloudflare templated guides to do this?
Excellent timing indeed (thank you), however, you don’t mention what class of paid Cloudflare subscription was required to execute this level of protection in your guide. That is not immaterial to ongoing costs. Could you reveal this please?
