You are able to register Fastify plugins like the rate limit one when configuring the server file but I’ve most often seen that done to limit api requests not web ones since most often the web side is still serves a SPA so there aren’t web route requests per se.
Which is why a 404 handler on web isn’t that common either since the requests made are for chunks of the distributed SPA and not get page 1 vs get page / as requests.
Ah this makes sense! So I better avoid it.
I followed the instructions for adding plugins. Just for the case of setNotFoundHandler I thought it would be great to have configuration options, since it is called in the redwood code base with a specific function and I did not want to copy paste it.
But since I do not seem to be in need, lets close this
fastify.setNotFoundHandler({
preHandler: fastify.rateLimit({
max: 4,
timeWindow: 500
})
}, function (request, reply) {
reply.code(404).send({ hello: ‘world’ })
})
I mean it’s up to you but are you trying to show a 404 when a rate limit hits? That seems counter productive since typically 1) your web assets should be on a CDN and never hit limits as that’s its purpose and 2) the rate limit plug-in and 429 error often includes headers to inform the client when next to retry and how many retries are available. So by hiding the 429 and headers you don’t let the client self heal and complete the request when the server is able.
The recommendation in the docs of fastify rate-limiting was, that it could limit rates on routes that do not exist. That was my goal. So a bot cannot try to guess endpoints so easily.
I guess for redwood there aren’t many though /graphql /auth? maybe some custom endpoints.
Oh I see now the scenario described – have to say that’s a new one for me but I can see why and how it could happened – learned something.
The scenario I imagine is:
- say have a Fastify server and takes requests
- a malicious agent could try to request random endpoints/routes/paths
- some might hit or not (for example I recall my Rails apps being hit with common “/admin” api requests or specific integration routs to see if using a service)
- but typically, the server would respond with the not found handler (not to be confused with RedwoodJS Not Found Page)
- if perhaps you have a not found handler that does some significant work or maybe renders a page with some assets (fonts, images, etc) that load could be significant
- so here they do tho things
- register a rate limiter for your apps routes
- for your fastify not found handler, rate limit that specifically so it isn’t abused and you check a million images from disk or whatnot
I get it.
Sure, I don’t see why you couldn’t do: GitHub - fastify/fastify-rate-limit: A low overhead rate limiter for your routes on the api side in running Fastify there.
Interesting scenario – had never thought of that case before. Thanks!
1 Like
Nice! I actually also only stumbled over it via their repo…