Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 88830 invoked from network); 15 May 2007 20:52:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 May 2007 20:52:56 -0000 Received: (qmail 83721 invoked by uid 500); 15 May 2007 20:53:02 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 83579 invoked by uid 500); 15 May 2007 20:53:01 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 83570 invoked by uid 99); 15 May 2007 20:53:01 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 May 2007 13:53:01 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 May 2007 13:52:54 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ho40Y-0005yZ-7l for dev@activemq.apache.org; Tue, 15 May 2007 13:52:34 -0700 Message-ID: <10630854.post@talk.nabble.com> Date: Tue, 15 May 2007 13:52:34 -0700 (PDT) From: bhartsb To: dev@activemq.apache.org Subject: Re: Correct way to removeDestinations() In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: bhartsb@cox.net References: <10448825.post@talk.nabble.com> <10619825.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org The reasons we need to delete were given as item 3 and 4. So will the method Andrew gave work? The method was: "add another method to AbstractRegion class, called removeDestinations(List destsToRemove) that would remove destinations which match the provided names in one single acquire-release-destinations-mutex step, and thus to avoid waiting for destinationsMutex during one by one deletion of destinations. " Regarding security, am I incorrect in thinking that giving untrusted clients the credentials to access the AMQ broker and (dynamically) create queues is a security risk? If I have thousands of clients and any hacker acquires these credentials then they can stage an attack on the AMQ. My business case is such that regular queues are the best fit, and surely other people working with AMQ, who are using regular queues widely (meaning AMQ is available over the Internet), are taking a security risk of attack with the current implementation. Am I wrong in my thinking? James.Strachan wrote: > > On 5/15/07, bhartsb wrote: >> >> >> We have a couple of issues that seem to preclude using temporary queues: >> >> 1. Our C++ clients that use the queues are utilizing STOMP to do so (we >> can't afford the time to retrofit the C++ apps for openwire at this >> juncture). STOMP as I understand does not support temporary queues. >> >> 2. Our C++ clients may temporarily lose a connection to the queues, but >> reconnect quickly. In this case we don't want to lose any messages. It >> seems from posts that a loss of connection would mean that the msgs in >> the >> queues (or still being added) are lost, because the queue connection >> would >> not be re-established. (Note: if the connection is lost for a long >> period >> then we do want to create a new queue). >> >> 3. We have our server telling the client applications, what queues to >> connect to. The Clients have no knowledge themselves of the queue they >> need >> to connect to, and it can be that a producer will connect before a >> consumer >> or vice versa. >> >> 4. We don't want client applications to be able to create queues >> themselves >> (only publish or consume). If we did allow them create/destroy >> priviledge >> then we would have to give the clients the proper JAAS credentials to >> allow >> this. But the client apps. will be in the public domain. If they have >> such >> credentials then there is a risk that a hacker could get one Client's >> credentials and gain access to the AMQ broker. This leaves the AMQ >> vulnerable to attack. This is not a risk we want to take. >> >> Now if I am wrong about 4 being a security/attack risk, then we could >> have >> the server pass the temporary queue name to the producer and consumer >> apps. >> But am I wrong? >> >> Finally, you mentioned to Andrew that AMQ queues are dynamic, but I don't >> see this as being the case if they can't be programatically deleted. I >> assume you weren't just talking about temporary queues when you said >> queues >> are dynamic. > > Any messaging client can talk to any new dynamic destination whenever > they like (assuming the security allows this) - there is no > administration required to create a queue - thats why I said they were > dynamic. > >> Please respond if you can to this and Andrews' prior question about his >> method of deleting queues (see his last post), and thank you. > > So i still don't get why you insist on deleting queues, rather than > just purging them. > > -- > James > ------- > http://macstrac.blogspot.com/ > > -- View this message in context: http://www.nabble.com/Correct-way-to-removeDestinations%28%29-tf3732843s2354.html#a10630854 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.