Brad Nicholes wrote:
Proposal for discussion: It was proposed that one way to handle host based as well as authz access control was to first reimplement the directives 'Alllow', 'Deny' and 'Order' as an authz provider (note: the authz-dev branch contains the current effort to convert all authz handlers to providers much like what was done for the authn providers). By reimplementing these directives as a provider, the same functionality could be achieved by using the 'Require' directive (ie. Require IP 192.168.0.1 or Require host mydomain.com). It was also proposed that a 'Reject' directive also be implemented to provide for the exception cases (ie. Reject IP192.168.0.5 or Reject host yourdomain.com).
To cast a somewhat wider net over this.The proxy framework's filter stack going to the backend seems to have similar requirements to "require" on the frontend.
In other words, just as you can say "require IP xx" on the frontend browser, you can also say "require IP yy" towards a backend server.
In a forward proxy situation you might use the reject directive as well: "reject host dodgy.site"
With the addition of fastcgi to the potential mod_proxy backends, proxy is becoming more and more "generic", where backend content providers are thought of as more "disconnected" than they are now.
It would be very cool if some of the authz providers could be used by the proxy as well, and we can get rid of the proxy specific Proxy* directives to do what require does.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
