Allow config.hosts proc to receive request object

[ajw725]

Didn't get much feedback from the core mailing list, but what I did get was encouraging.

Summary

I wanted a way to skip the host authorization check - which I want to use in production as protection against host header poisoning - for a specific endpoint. With my application set up behind a load balancer on AWS, the host that the application sees on the health check is the IP address of the load balancer, which can change and therefore can't be hard-coded into my application. There is nothing sensitive at the health check endpoint, and I'd like to just skip the check there.

In a Rails 5 app, I just implemented the host filtering stuff in my own custom middleware. I guess I could keep doing that on Rails 6, but since Rails now has its own middleware for this, it seems like all of that functionality should be kept in one place if possible.

ActionDispatch::HostAuthorization accepts a list of allowed values via config.hosts. An item in this list can be anything that responds to ===, which includes a Proc. Passing the entire request object - in addition to the host value - to such a Proc allows for customization like skipping the host authorization check on a particular endpoint, e.g. a health check.

Usage

Rails.application.configure do
  config.hosts += [
    'myapp.com',
    proc { |_host, req| req.path == '/healthcheck' }
  ]
end

Or just

Rails.application.configure do
  config.hosts << proc { |host, req| host == 'myapp.com' || req.path  == '/healthcheck' }
end

Questions and concerns

• Is passing the request object back into the Proc on every request too unwieldy?
• Would it be clearer to do allowed.call instead of trying to keep using === for everything?

[eugeneius]

This problem was solved in #38829 by adding a separate exclude option, which is actually closer to your original proposal on the mailing list. I preferred that approach since allowing entries in config.hosts to classify requests by something other than their host felt wrong. Thanks for working on this, and sorry we couldn't go with your implementation.

[ajw725]

Thanks for the update, @eugeneius . Sounds good - glad it's getting implemented in some form!