Hi Keith, thanks for explanation.
It will be great if you can post skeletal code of ACL module. Tomas Keith Wall wrote > Hi Tomas > > Unfortunately, Broker-J's access_control plugin is not too good. It > is something we would like to rework when schedules allow. The > current module actually uses an object modal that pre-dates the > current one - which leads to user confusion and an ugly adaption layer > in the code. The ACL also assumes AMQP 0-x conventions - publishing > only to exchanges and consuming from queues when expressing rules > which creates a further wrinkle when using AMQP 1.0. > > The current module lets you specify rules that match objects using > zero or more property qualifiers (e.g. name="foo" or type="fanout"), > so it is possible to write rules about named objects in your system > and all objects matching certain criteria. For temporary queues, > this doesn't work well as you have discovered. It is possible to say > that user foo can (or cannot) consume from any temporary queue using > the temporary=true qualifier, but it is not possible to be specific, > but you cannot express a rule that gives users to temporary queues > that they have created. > > The ACL mechanism is pluggable - so it would be possible to write a > module that would give the behaviour you need. You would need to look > at the AccessControlProvider and AccessControl interfaces. The Broker > supports one or more access control providers. It consults each > AccessControlProvider in order until one make a decision that is not > DEFER. So you could hopefully write a simple ACL module that you give > you the additional behaviour you need and fallback on access_control > plugin for everything else. If you want to explore this route, I > could share some skeletal code to help get you started. > > Turning to your last point, when using AMQP 1.0 and wishing to > permission publishing directly to queues, as access_control plugin > knows only AMQP 0-x conventions you have to permission the default > exchange. > > ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName" > > Hope this helps. > > Keith > > On 5 April 2018 at 14:46, Vavricka < > vavricka.tomas@ > > wrote: >> Hi, >> >> I am trying to get working temporary queues on Java Broker. Each user >> should >> have access only to queue which he created. >> >> ACL rights: >> >> ACL ALLOW-LOG user1 ACCESS VIRTUALHOST >> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1" >> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1" >> >> ACL ALLOW-LOG user2 ACCESS VIRTUALHOST >> ACL ALLOW-LOG user2 CREATE QUEUE temporary="true" owner="user2" >> ACL ALLOW-LOG user2 CONSUME QUEUE temporary="true" owner="user2" >> >> I successfully create temporary queue by JMS method "TemporaryQueue >> temporaryQueue = session.createTemporaryQueue()", queue is correctly >> created >> on broker, but owner is not set in webgui (however createdBy and >> lastUpdatedBy in JSON is correctly set to corresponding user). >> >> When I try to create consumer by "MessageConsumer consumer = >> session.createConsumer(temporaryQueue)", I get "Permission CREATE is >> denied >> for : Consumer ...". When owner is not set in CONSUME ACL I can create >> consumer without error, but both users can consume same queue. Is there >> any >> different way to distinguish temporary queues, so one user cannot read >> other >> user messages? >> >> Another issue is I cannot sent messages directly to temporary queue. When >> I >> try to send message I get error "Permission PERFORM_ACTION(publish) is >> denied for : Queue 'TempQueueba2f889e-f95c-49d4-8c15-023e62666320'". We >> could utilize sending messages directly to queue, because we cannot >> dynamically create exchange binding by REST API. Or is there any way to >> set >> bindings by JMS? >> >> Java Broker 7.0.3 >> Qpid JMS client 0.31.0 >> >> Tomas >> >> >> >> -- >> Sent from: >> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: > [email protected] >> For additional commands, e-mail: > [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [email protected] > For additional commands, e-mail: > [email protected] -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
