3 ms·

Rack Attack – Rails Tricks

16 points by Alifatisk 3y ago

revskill 3y ago
The problem with Rails in general, is it hard to reuse html form component with is interactive. It's not worth the effort. DHH attitude toward modern FE toolings is insane.
- pil0u 3y ago
  Turbo[0] has been solving this for years. Quite the contrary, front-end frameworks have started to think "sending JSON is good, but actually sending HTML could be great!". DHH's presentation[1] during Rails World 2023 is quite interesting in that regard, I recommend you give it a go (start around minute 16). I am actually very excited with his vision of the web. [0] https://turbo.hotwired.dev/ https://turbo.hotwired.dev/ [1] https://www.youtube.com/watch?v=iqXjGiQ_D-A https://www.youtube.com/watch?v=iqXjGiQ_D-A
  - revskill 3y ago
    No, by just sending HTML over the wire doesn't make your HTML interactive the way you want.
    - Alifatisk 3y ago
      Why? The difference here is that the computation is done on the server side. The end result is still the same, just different approaches.
      - revskill 3y ago
        You need a "hydration" process to hydrate all event handlers. So only html doesn't buy this argument right ? And do not tell me to "findMyStateFromADomNode", i don't store state in the DOM.
        Alifatisk 3y ago
        I think Turbo surgically replaces parts of the DOM with the new response from the server.
ewalk153 3y ago
Redirecting to a dedicate 404 page is bad SEO practice. There must be a better way to accomplish this.
- Arnt 3y ago
  This is the better way. The redirection happens inside the server. Rack Attack runs early in the request processing and says "do the rest of the processing as if the client's request were for a page that does not exist", then the server acts accordingly.
- kawsper 3y ago
  It's also a bad user experience. If I mistyped a URL, and just need to change one letter, now I can't because I've been redirected.
  - Arnt 3y ago
    You haven't been redirected. The redirection happens inside the server, it's never communicated to the client. Well, almost inside the server. The server first does TLS processing, then this part, then that which the backend developers see as "the server". From a backend developer's perspective, this code runs in the zone between browser and server, where load balancers and such live. Operationally the code runs on in the same rack, probably on the same CPU, as the backend code.
    - kawsper 3y ago
      Ah that's cool, I noticed the other interaction yesterday where I was 301 redirected on a 404, I thought it was the same here.
      - Arnt 3y ago
        People make all kinds of mistakes.
- pmontra 3y ago
  Almost all the Rails apps I worked on in the past 18 years don't care about SEO because they don't have much that googlebot can browse without an account. Everything important is either behind a login form or served through an API. The API is probably used by a JS frontend, which googlebot browses, and it's up to the frontend to deal with 404 and other errors in a gracious way. Finally, if the API is machine to machine, there are no worries about SEO.
pgraf 3y ago
Why not adhere to the HTTP standard for once and return a 429 Too many requests or 403 Forbidden? 404 Not Found should only be used for “Not Found” errors. If adhered to this posts advice, you can really screw your search ranking if a major web crawler gets blocked and de-lists all of your pages because of 404
- Alifatisk 3y ago
  I think you can still adhere to the HTTP standards (Rails have built-in keywords for those aswell). This article just talks about blocking hosts that make too many requests to a 404 page (I guess because it's crawling?) and how to mitigate those using Rack Attack.
  - pgraf 3y ago
    Could you please explain how sending a 404 to clients sending too many requests would adhere to the HTTP standards? I’m not against the blocking itself. For reference: https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4
    - Alifatisk 3y ago
      When I say you can still adhere to the HTTP standards, I mean that you just have to adjust the suggested settings in the config, so requests reaching over the throttle should give 429 instead of 404: Like the following: # config/routes.rb get "429", to: "welcome#429", code: 429 rescue_from ActiveRecord::RecordNotFound, with: :too_many_requests def too_many_requests redirect_to "/warning" end # config/initializers/rack-attack.rb class Rack::Attack ... blocklist("block 429") do |request| Allow2Ban.filter("too_many_requests-#{request.ip}", maxretry: 5, findtime: 3.minutes, bantime: 1.day) do request.path == '/429' end ... end # config/initializers/rack-attack.rb Rack::Attack.blocklisted_responder = lambda do |request| [ 429, {}, ["You are blocked. If you think are not a bot and you think it was due to a mistake, reach out to us at support@yourdomain.com"]] end The way I interpreted the article wasn't to redirect everything to a 404 page, but how to handle massive amount of requests to a 404 page!

16 points by Alifatisk 3y ago

The problem with Rails in general, is it hard to reuse html form component with is interactive. It's not worth the effort. DHH attitude toward modern FE toolings is insane.

pil0u 3y ago
Turbo[0] has been solving this for years. Quite the contrary, front-end frameworks have started to think "sending JSON is good, but actually sending HTML could be great!". DHH's presentation[1] during Rails World 2023 is quite interesting in that regard, I recommend you give it a go (start around minute 16). I am actually very excited with his vision of the web. [0] https://turbo.hotwired.dev/ https://turbo.hotwired.dev/ [1] https://www.youtube.com/watch?v=iqXjGiQ_D-A https://www.youtube.com/watch?v=iqXjGiQ_D-A
- revskill 3y ago
  No, by just sending HTML over the wire doesn't make your HTML interactive the way you want.
  - Alifatisk 3y ago
    Why? The difference here is that the computation is done on the server side. The end result is still the same, just different approaches.
    - revskill 3y ago
      You need a "hydration" process to hydrate all event handlers. So only html doesn't buy this argument right ? And do not tell me to "findMyStateFromADomNode", i don't store state in the DOM.
      - Alifatisk 3y ago
        I think Turbo surgically replaces parts of the DOM with the new response from the server.

ewalk153 3y ago

Redirecting to a dedicate 404 page is bad SEO practice. There must be a better way to accomplish this.

Arnt 3y ago
This is the better way. The redirection happens inside the server. Rack Attack runs early in the request processing and says "do the rest of the processing as if the client's request were for a page that does not exist", then the server acts accordingly.
kawsper 3y ago
It's also a bad user experience. If I mistyped a URL, and just need to change one letter, now I can't because I've been redirected.
- Arnt 3y ago
  You haven't been redirected. The redirection happens inside the server, it's never communicated to the client. Well, almost inside the server. The server first does TLS processing, then this part, then that which the backend developers see as "the server". From a backend developer's perspective, this code runs in the zone between browser and server, where load balancers and such live. Operationally the code runs on in the same rack, probably on the same CPU, as the backend code.
  - kawsper 3y ago
    Ah that's cool, I noticed the other interaction yesterday where I was 301 redirected on a 404, I thought it was the same here.
    - Arnt 3y ago
      People make all kinds of mistakes.
pmontra 3y ago
Almost all the Rails apps I worked on in the past 18 years don't care about SEO because they don't have much that googlebot can browse without an account. Everything important is either behind a login form or served through an API. The API is probably used by a JS frontend, which googlebot browses, and it's up to the frontend to deal with 404 and other errors in a gracious way. Finally, if the API is machine to machine, there are no worries about SEO.

pgraf 3y ago

Why not adhere to the HTTP standard for once and return a 429 Too many requests or 403 Forbidden? 404 Not Found should only be used for “Not Found” errors. If adhered to this posts advice, you can really screw your search ranking if a major web crawler gets blocked and de-lists all of your pages because of 404

Alifatisk 3y ago
I think you can still adhere to the HTTP standards (Rails have built-in keywords for those aswell). This article just talks about blocking hosts that make too many requests to a 404 page (I guess because it's crawling?) and how to mitigate those using Rack Attack.
- pgraf 3y ago
  Could you please explain how sending a 404 to clients sending too many requests would adhere to the HTTP standards? I’m not against the blocking itself. For reference: https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4
  - Alifatisk 3y ago
    When I say you can still adhere to the HTTP standards, I mean that you just have to adjust the suggested settings in the config, so requests reaching over the throttle should give 429 instead of 404: Like the following: # config/routes.rb get "429", to: "welcome#429", code: 429 rescue_from ActiveRecord::RecordNotFound, with: :too_many_requests def too_many_requests redirect_to "/warning" end # config/initializers/rack-attack.rb class Rack::Attack ... blocklist("block 429") do |request| Allow2Ban.filter("too_many_requests-#{request.ip}", maxretry: 5, findtime: 3.minutes, bantime: 1.day) do request.path == '/429' end ... end # config/initializers/rack-attack.rb Rack::Attack.blocklisted_responder = lambda do |request| [ 429, {}, ["You are blocked. If you think are not a bot and you think it was due to a mistake, reach out to us at support@yourdomain.com"]] end The way I interpreted the article wasn't to redirect everything to a 404 page, but how to handle massive amount of requests to a 404 page!