+1 to this proposal. Re: queueDelete/exchangeDelete events - my preference would be to add an "autoDel" flag to the existing events, setting it true in the case of the auto delete, and false if the delete occurred by mgmt request. I suppose, on auto-delete 'rhost' and 'user' would take on the broker's process name and (one of?) its public addresses.
----- Original Message ----- > From: "Gordon Sim" <g...@redhat.com> > To: users@qpid.apache.org > Sent: Wednesday, June 19, 2013 7:29:19 AM > Subject: [c++]: autodelete, authorisation and QMF event > > The c++ broker currently checks for delete permission when autodeleting > a queue. Where the queue is also exclusive, this is when the 'owning' > session ends. Where it is not exclusive, this is when the last consumer > cancels. > > I think checking permission for the delete is wrong in both these cases, > perhaps especially so for the second case. A consumer should not need > permission to delete the queue in order to cancel their subscription. > The appropriate means to authorise autodelete is at the point the queue > is created. > > Now, it is true that you can restrict the delete permission to be > granted only if the autodelete property is set on the queue, but that > doesn't enforce that the queue is actually autodeleted. A consumer with > the appropriate permission could delete the queue while it was still in > use by other consumers. (You can't it seems allow delete only if unused > or empty). > > I would like to remove the authorisation for delete from actions that > trigger autodelete. Does anyone object or think that is a bad idea? > > Though only tangentially related, and a lot less severe in its > implications, I think it is also not strictly correct to put the > consumers username and host details in the queue-delete event that is > sent for autodeleted queues. Ideally autodeletion would be signalled by > a flag in the event or even a different type of event, but I think in > any case it would be better to indicate that it was the _broker_ that > deleted the queue, not the client who happened to be the last to use it. > > Again, would anyone object to a change along those lines or see any > problem with it? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
