> Did you setup dynamic or static federation routes? Dynamic routes will > require ACL to setup > subscriptions on-demand which can be blocked via ACL. static would have then > pre configured... > > There might be a case here for another action for dynamic links -- but lets > try work through the details > first. (are you doing dynamic or static federation routes ?) >
This is with static routes. I haven't done any testing with dynamic routes. It was created with: # qpid-route route add router/rou...@localhost:5672 router/rou...@localhost:5671 amq.direct mykey The actual message transfer seems to be working just fine (as long as I set up a 'allow allow-log all all' ACL rule. With a default 'allow' ACL, sending to the amq.direct exchange with the routing key of 'mykey' gets to the right queue on the destination broker. With anything tighter, ACL-wise, it gets denied by the destination broker when the publish action occurs, since according to the logs, it's trying to do the publish action without an authenticated ID. I'd have expected that when the destination broker goes to evaluate its ACLS that either the user used to send the message to the source side (in the log above, user 'mark') would be used -- either because the setting up of the federated link would create some sort of trust relation or by just sending along the original authentication credentials -- or that it would use the user used to create the federated link (user 'router' here). I'm assuming that there's some option I'm missing, either in the 'route add' command or perhaps in the message's delivery properties but I haven't yet been able to dig up what that might be. Thanks! --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
