using X-Forwarded-For header in access controls

I have a situation where requests from end users pass through one or
more other proxies before getting to a Squid proxy that I care about. I
want Squid's access controls and logging to use the IP address of the
original client (let's call it the indirect client address) instead of
the IP ddress of the direct client (which is a downstream proxy). The
indirect client address can be obtained by walking backwards through the
X-Forwarded-For header until you reach an address that's not trusted for
this purpose, or until there are no more addresses to consider.

For example, if a request arrives from client A, and contains
"X-Forwarded-For: F, E, D, C, B", and all of A, B and C are trusted
to set a valid X-Forwarded-For header, but D is not trusted, then the
indirect client address would be D.

I have implemented code to handle the following syntax in squid.conf:

        # Requests from my_downstream_proxy have their X-Forwarded-For
        # header parsed to find the indirect client address.
        acl my_downstream_proxy <address>
        follow_x_forwarded_for allow my_downstream_proxy

        # The indirect client address gets used instead of the
        # direct client address in ACLs, delay pools and the access log.
        acl_uses_indirect_client on
        delay_pool_uses_indirect_client on
        log_uses_indirect_client on

Is this of interest to anybody? If so, where do I send the patches?

I also have a question about ACLs. If I create an ACL using
http->acl_checklist = clientAclChecklistCreate(...), and then follow it
using aclNBCheck(...), what is the proper way of cleaning up? I see
some existing code simply does http->acl_checklist = NULL, while other
existing code uses aclChecklistFree().

--apb (Alan Barrett), about to subscribe to the list
Received on Thu Nov 14 2002 - 12:35:49 MST