Replies: 2 comments
|
And now that we're at it.... Something that also feels kind of annoying is the need to name every query that you want to refresh. The justification for that API is bundle size and, again, DoS. My thinking about DoS protection in this regard is the same as above: It's not really solving the problem, and solving it for every API would make things a mess. This should be done at a different level/layer in my opinion. And regarding bundle size.... I understand it could be a problem for people using Vercel or similar services, but I run this on my own server, and I honestly couldn't care less about server side bundle sizes. So again, this is making the APIs far worse for little to no benefit from my point of view. I wonder if there could be a setting to just "accept and auto run any client requested query refresh" (provided you understand these trade offs) and then leave the current APIs for those who really want low level control over this. It would make this feature so much nicer to use. |
|
When evaluating DoS vectors, the thing you care about is assymetry. Of course you can attempt to DoS something by spamming it with requests, but that consumes the attacker's resources as well as the defender's, and is relatively straightforward to protect yourself against. The damage is therefore self-limiting. If the attacker can send a single request with a small payload that causes a large amount of work, you are much, much more vulnerable. Having an API that makes that explicit is the correct tradeoff. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I just listened to a podcast episode where @Rich-Harris said that a great way to help is providing feedback about new features, so here's my attempt to do so.
I've been using the experimental Remote Functions feature, and I love them. But one thing that really bothers me, is the
limitargument for therequestedfunction used in client requested refreshes (see here).I do understand the reasoning for having that argument. But I can't avoid thinking it isn't solving any real problem while making the API worse (or at least, more annoying to use , to me at least).
If you don't trust the client because it would send malicious requests that would DoS your server, then what prevents the client from repeating in a loop these calls? Wouldn't that cause the issue anyways? If we start being this protective, where do we put the limit? wouldn't we need to rate limit all over the place?. I do understand why that's there. But I think that the worsening of the API is not worth at all the benefit it provides, and providing a real benefit of preventing DoS'ing your server would take much more than this, and should probably be done at a higher layer (like an app firewall, or a rate/time/size limiting middleware, etc).
Anyways, just my 2 cents after having used these APIs.
All reactions