Support for subdomains about rack-attack HOT 5 CLOSED

For your use case, you could pretty easily do:

blacklist('Secure admin interface by IP') do |req|
    # Request are blocked if the return value is truthy
    # Check to see if this is an admin interface request and that the
    # IP is not included in the environments whitelist.
    req.host.split('.').first == 'admin' && ENV['ADMIN_IP_WHITELIST'].exclude?(req.ip)
end

I have a feeling that adding a subdomains helper method might be out of scope since it's pretty easy for most people to write their own. I'm not actually even sure why there's a Rack::Attack::Request object -- I can't find anywhere in the code that it's used. Perhaps @ktheory could weigh in?

from rack-attack.

Thanks for the suggestion! And I do agree that this use case probably is outside of scope - just thought it was worth floating the idea.

The Rack::Attack::Request object is just a simple facade for the sake of abstraction by the looks of things - it does nothing but extend the Rack::Request.

It might be nice to make the Request class configurable though, that way I could include the logic as I proposed without monkey patching.

Sent from my iPhone

On 17 Jun 2014, at 18:10, Zach Millman [email protected] wrote:

For your use case, you could pretty easily do:

blacklist('Secure admin interface by IP') do |req|
# Request are blocked if the return value is truthy
# Check to see if this is an admin interface request and that the
# IP is not included in the environments whitelist.
req.host.split('.').first == 'admin' && ENV['ADMIN_IP_WHITELIST'].exclude?(req.ip)
end
I have a feeling that adding a subdomains helper method might be out of scope since it's pretty easy for most people to write their own. I'm not actually even sure why there's a Rack::Attack::Request object -- I can't find anywhere in the code that it's used. Perhaps @ktheory could weigh in?

—
Reply to this email directly or view it on GitHub.

Support Time Limited is a company registered in England and Wales. Registered number: 06527328. Registered office: 145-157, St. John Street , London, EC1V 4PW.

from rack-attack.

@SirRawlins, @zmillman Yup, I agree that a subdomains method is out of scope for Rack::Attack.

You can easily add it to your app; or not-so-easily convince the rack maintainers to add it to Rack::Request.

It might be nice to make the Request class configurable though

@SirRawlins, I'm not how you mean. Please elaborate.

Closing the issue b/c there's no further action needed.

from rack-attack.

@ktheory thanks for getting back to me.

With regards to the configurable class my thoughts are that we drop the Rack::Attack::Request class all together as it's not adding any functionality, and instead have the lib directly reference Rack::Request.

However, this could be overridden in the config such as.

config.request_class => MyApp::MyRequestClass

My request class could then extend the Rack::Request, adding any functionality required, but without having to reopen the Request class and monkey patch any behaviour.

The end result is little different to what I've outline above, it's just a little tidier as it removed the need to Monkey Patch.

from rack-attack.

@SirRawlins: I really like how straightforward the method definition for call is in the README. Since Rack::Attack::Request is already designated as a safe place to add monkey patch helpers, it seems like it's unnecessary to add more configuration options. The change probably wouldn't make the code tidier for 90% of devs using Rack::Attack.

from rack-attack.