4 ms·

For regular public web pages, serving the actual fucking page should not be more expensive than serving the captcha page! What the hell is a "bad actor" in rela

For regular public web pages, serving the actual fucking page should not be more expensive than serving the captcha page! What the hell is a "bad actor" in relation to GET requests to a public page? To a public page, all actors should be inherently neutral.

ehutch79 5y ago
There's a lot of potential side effects. Not every GET request retrieves a static asset. A list view with filters for instance. Either way, you could be dumping any arbitrary data along with a request. Or just try fuzzing parameters. some pages might be poorly done graphQL endpoints, and your might find your db tied up. There are MANY ways a legit a get request can cause issues, let alone someone with bad intentions.
- ipaddr 5y ago
  All users are hostile users and all users are preferred users. Define what your system will allow through rate limits and caching. Assume users would destory your site if given the chance because they will. If you are exposing private data through graphgl config it or drop the private data or drop graphgl and user a backend.
  - ehutch79 5y ago
    I 100% agree you should be looking at all incoming traffic as hostile or at least potentially hostile. The other comments are contending that there's nothing a hostile user could do to a 'public' page. One of the things using cloudflare gets you is all those protections without having to know how to do them yourself. Which a lot of the developers don't know how to do. There's also something to be said for catching a lot of this at the network layer on a cluster of machines that can handle any incoming traffic that your one poor neglected vm can't.
    - ipaddr 5y ago
      If you use cloudflare you give up freedom not to force captcha. If you avoid them you can choose where you want to captcha. When cloudflare goes down you go down unnecessarily. If worried about a ddos attack cloudflare or another provider might be a good choice. But adding ddos support by default seems unncessary. In my 20 years of running 100s of sites I haven't run into a situation where I need ddos support. The vast majority will never be the target. Once in awhile google or bing will ddos you but using cloudflare to block that seems like overkill.
    - ehutch79 5y ago
      There are tradeoffs, yes. We might weight those tradeoffs differently. That's ok.
    - floatboth 5y ago
      Cloudflare gets you very paranoid, overly aggressive, user-hostile protections by default – and people just take the defaults even if they use it with STATIC HOSTING LIKE GITHUB PAGES!

ehutch79 5y ago

There's a lot of potential side effects. Not every GET request retrieves a static asset. A list view with filters for instance. Either way, you could be dumping any arbitrary data along with a request. Or just try fuzzing parameters. some pages might be poorly done graphQL endpoints, and your might find your db tied up. There are MANY ways a legit a get request can cause issues, let alone someone with bad intentions.

ipaddr 5y ago
All users are hostile users and all users are preferred users. Define what your system will allow through rate limits and caching. Assume users would destory your site if given the chance because they will. If you are exposing private data through graphgl config it or drop the private data or drop graphgl and user a backend.
- ehutch79 5y ago
  I 100% agree you should be looking at all incoming traffic as hostile or at least potentially hostile. The other comments are contending that there's nothing a hostile user could do to a 'public' page. One of the things using cloudflare gets you is all those protections without having to know how to do them yourself. Which a lot of the developers don't know how to do. There's also something to be said for catching a lot of this at the network layer on a cluster of machines that can handle any incoming traffic that your one poor neglected vm can't.
  - ipaddr 5y ago
    If you use cloudflare you give up freedom not to force captcha. If you avoid them you can choose where you want to captcha. When cloudflare goes down you go down unnecessarily. If worried about a ddos attack cloudflare or another provider might be a good choice. But adding ddos support by default seems unncessary. In my 20 years of running 100s of sites I haven't run into a situation where I need ddos support. The vast majority will never be the target. Once in awhile google or bing will ddos you but using cloudflare to block that seems like overkill.
  - ehutch79 5y ago
    There are tradeoffs, yes. We might weight those tradeoffs differently. That's ok.
  - floatboth 5y ago
    Cloudflare gets you very paranoid, overly aggressive, user-hostile protections by default – and people just take the defaults even if they use it with STATIC HOSTING LIKE GITHUB PAGES!