Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
0.18
-
None
Description
The Acl interface to the broker during and exchange bound function includes an extraneous binding key parameter.
The functions that trigger this lookup are illustrated here:
COMMAND LINE
./spout "x-usera-1/a.x"
ON THE WIRE
2012-12-04 15:55:25 [Protocol] trace RECV [127.0.0.1:5672-127.0.0.1:46894]: Frame[BEbe; channel=1; {ExchangeBoundBody: exchange=x-usera-1; queue=x-usera-1; binding-key=; arguments={}; }]
ACL LOOKUP
2012-12-04 15:55:25 [Security] debug ACL: Lookup for id:anonymous action:access objectType:exchange name:x-usera-1 with params
The user application is passing the binding key 'a.x' to the messaging client. However, the messaging client does not pass the binding key to the broker during the ExchangeBoundBody message. As a result the broker Acl lookup uses a blank routingkey.
If the broker is configured with an Acl file that has an ACCESS EXCHANGE rule that specifies a routingkey then that rule will never match.
The suggested change is to deprecate the routingkey property in the Acl ACCESS EXCHANGE rule processing. If a routingkey is specified then it will be ignored and a warning message will be issued.
If customers have 'access exchange' rules that use routingkey values specified then the Acl behavior may start matching rules that did not match before. However the log file will have an Acl warning and the broker will not fail to boot due to an Acl file processing error.