[
https://issues.apache.org/jira/browse/TS-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1983:
---------------------------
Assignee: Alan M. Carroll
> ACL rules in remap.config does not take precedence over rules in
> ip_allow.config
> --------------------------------------------------------------------------------
>
> Key: TS-1983
> URL: https://issues.apache.org/jira/browse/TS-1983
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
> Reporter: Leif Hedstrom
> Assignee: Alan M. Carroll
> Labels: incompatible
> Fix For: 8.0.0
>
>
> Lets say you want to allow DELETE for a small sub-set of requests, based on
> remap.config rules. The reasonable configuration is to do e.g.
> {code}
> map http://dav.example.com http://127.0.0.1 @method=DELETE @action=allow
> {code}
> However, this does not work, since the global "DENY" in ip_allow.config takes
> precedence (it denies all DELETE's). This is actually sort of a regression I
> think, it did not use to behave like this I'm fairly certain.
> The workaround (which is incredibly cumbersom if you have even a moderately
> large remap.config, is to inverse the rules. E.g.
> {code}
> src_ip=0.0.0.0-255.255.255.255 action=ip_deny
> method=PUSH|PURGE
> {code}
> and
> {code}
> map http://other.example.com http://123 @method=DELETE @action=deny
> map http://another.example.com http://123 @method=DELETE @action=deny
> map http://more.example.com http://123 @method=DELETE @action=deny
> .
> .
> .
> {code}
> This kinda sucks to maintain, and also opens up a PEBKAC security problem,
> when someone adds a new remap.config rule and forgets to deny the DELETEs.
> I really feel that the ACLs from remap.config (if they match, you can specify
> IP ranges etc. as well), should take precedence over ip_allow.config.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
