-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for subdomains #73
Comments
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 |
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 notifications@github.com wrote:
Support Time Limited is a company registered in England and Wales. Registered number: 06527328. Registered office: 145-157, St. John Street , London, EC1V 4PW. |
@SirRawlins, @zmillman Yup, I agree that a You can easily add it to your app; or not-so-easily convince the rack maintainers to add it to Rack::Request.
@SirRawlins, I'm not how you mean. Please elaborate. Closing the issue b/c there's no further action needed. |
@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.
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. |
@SirRawlins: I really like how straightforward the method definition for |
I've been implementing rack-attack this morning but had a requirement to work with the request based on it's subdomain, rather than path.
It seem that the
Rack::Request
class doesn't provide any way to access the subdomain of the request, which made things a little tricky.At the moment I have borrowed a similar approach to the one described here http://tannerburson.com/2009/01/extracting-subdomains-in-sinatra.html/ but instead monkey-patched the
Rack::Attack::Request
class to provide the subdomains method. a'laThis then allows me to apply rules based on the subdomain, like this:
Do you think there is an argument for adding this to rack-attack code base? If so I'd be happy to put together a pull-request.
Robert
The text was updated successfully, but these errors were encountered: