Rack::Attack VS Huginn

The first line of defense should be to put rate-limiting on your login endpoints. rack-attack can help with that. I recommend to limit the login attempts to 5 per minute for a username and block the IP for 30 minutes. You should also limit the number of login attempts from the same IP address, but this needs to be adjusted to the application you are working on, because if it is a tool used in classrooms, it might be legit to have 50 logins within a few minutes from the same IP. (I have a few post written about rack-attack)

Rack::Attack

Rack middleware for blocking & throttling abusive requests. Protect your Rails and Rack apps from bad clients. Rack::Attack lets you quickly decide when to allow, block, and throttle based on the properties of the request. Using this gem you can save your web application from attacks, we can whitelist IPs, Block requests according to requirements, and many more… Install Rack-attack gem: # In your Gemfile gem 'rack-attack' Enter fullscreen mode Exit fullscreen mode Plugging into the application Then tell your ruby web application to use rack-attack as a middleware. # config/application.rb # rack attack middleware config.middleware.use Rack::Attack Enter fullscreen mode Exit fullscreen mode Once you’ve done that, you’ll need to configure it. You can do this by creating the file, config/initializers/rack-attack.rband adding the rules to fit your needs. You can disable it permanently (like for a specific environment) or temporarily (can be helpful for specific test cases) by writing: Usage Safe listing Safelists have the most precedence, so any request matching a safelist would be allowed despite matching any number of blocklists or throttles. safelist_ip(ip_address_string) Rack::Attack.safelist_ip(“5.6.7.8”) Enter fullscreen mode Exit fullscreen mode safelist_ip(ip_subnet_string) Rack::Attack.safelist_ip(“5.6.7.0/24”) Enter fullscreen mode Exit fullscreen mode safelist(name, &block) Name your custom safelist and make your ruby-block argument return a truthy value if you want the request to be allowed, and false otherwise. Blocking blocklist_ip(ip_address_string) Rack::Attack.blocklist_ip(“1.2.3.4”) Enter fullscreen mode Exit fullscreen mode blocklist_ip(ip_subnet_string) Rack::Attack.blocklist_ip(“1.2.0.0/16”) Enter fullscreen mode Exit fullscreen mode blocklist(name, &block) Name your custom blocklist and make your ruby-block argument return a truthy value if you want the request to be blocked, and false otherwise. Throttling *throttle(name, options, &block) *( provide limit and period as options) Throttle state is stored in a configurable cache (which defaults to Rails.cache if present). Name your custom throttle, provide limit and period as options, and make your ruby-block argument return the discriminator. This discriminator is how you tell rack-attack whether you’re limiting per IP address, per user email, or any other. For example, if we want to restrict requests other than defined routes and display a custom error page. Error page: If we want to restrict requests/IP and if the request limit increases then send a reminder mail. For Example, we want to allow only 300 requests per 30 seconds after that will restrict requests from this IP till the next 30 seconds interval starting. Get error mail if the limit is extended. Performance The overhead of running Rack::Attack is typically negligible (a few milliseconds per request), but it depends on how many checks you’ve configured, and how long they take. Throttles usually require a network roundtrip to your cache server(s), so try to keep the number of throttle checks per request low. If a request is blocklisted or throttled, the response is a very simple Rack response. A single typical ruby web server thread can block several hundred requests per second. Sample rack-attack.rb file For more information: https://github.com/rack/rack-attack If this guide has been helpful to you and your team please share it with others!

Second vote for rack-attack!

You could use something like Rack Attack to mitigate this type of behavior if it becomes an issue.

The final gem I like to include in all projects is rack-attack. This is a rate limiting tool which is great for throttling dangerous actions in your app to prevent bot attacks or other malicious users.

rack-attack to prevent bruteforce and DDoS attacks

Check out Rack Attack. It lets you block bots that make requests too fast to be real users, or that request obviously-suspect URLs (/phpmyadmin for example). There are lots of other options, but those are the quick wins IMO.

I skipped to chapter 9 in the article ("Clogged"), and it looked like Pipes failed because it didn't have a large enough team or a well-defined mission. As a result they couldn't offer a super robust product that would lure in enterprise users. "You could not purchase some number of guaranteed-to-work Pipes calls per month" is the quote from the article.

The reason I think that interesting is because that's the model these days for everything from AI tokens to Monday.com seats. It makes me feel like Pipes was before its time.

That said I've been collecting different "business glue" products that are similar to Pipes. To me, like you say, they aren't as interesting, exciting and intuitive as Pipes was, but maybe it just takes a little more digging. I tried to focus on open source tools but some aren't.

- n8n io: https://n8n.io/integrations/mondaycom/

- Node-RED: https://nodered.org/ (just read about this one in this thread)

- trigger dev: trigger.dev

- automatisch.io: https://automatisch.io/docs/

- Activepieces: https://www.activepieces.com/docs/getting-started/introducti...

- Huginn: https://github.com/huginn/huginn

- budibase: https://budibase.com/

- windmill: https://www.windmill.dev/

- tooljet: https://www.tooljet.com/workflows

- Bracket: https://www.usebracket.com/pricing (just SalesForce <-> PostgreSQL)

- Zapier: zapier.com/

Anyway I hope some of these are fun!

"correct" is a value judgement that depends on lots of different things. Only you can decide which tool is correct. Here are some ideas:

- https://camel.apache.org/

- https://www.windmill.dev/

- https://github.com/huginn/huginn

Your idea about a queue (in redis, or postgres, or sqlite, etc) is also totally valid. These off-the-shelf tools I listed probably wouldn't give you a huge advantage IMO.

Huginn (https://github.com/huginn/huginn) has like some 39K stars on Github and the use cases it covered looks good.

Huginn is an another useful tool that allows you to wrangle CSS selectors and XPath nodes to create RSS feeds.

I use it quite successfully to get data out of undocumented APIs and out into RSS.

https://github.com/huginn/huginn

I know of Huginn that could be usefull depending on what you want to do.

https://github.com/huginn/huginn ??

Huginn

"not a single word about the safety implications of such a system"

Oh please. Not everything has to be regulated-to-hells before a use case is even found on this. Autonomous agents have existed for decades.

If it can automate agents like huginn[0] with natural language, I'd be very happy. Autonomous agents doesn't mean it's going to take over the world autonomously. Let's lower the fearmongering a bit.

[0]: https://github.com/huginn/huginn