Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 6355 invoked from network); 1 Sep 2002 14:58:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Sep 2002 14:58:05 -0000 Received: (qmail 22721 invoked by uid 97); 1 Sep 2002 14:58:37 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 22704 invoked by uid 97); 1 Sep 2002 14:58:37 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 22686 invoked by uid 98); 1 Sep 2002 14:58:36 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D722AF7.4040702@thinkdynamics.com> Date: Sun, 01 Sep 2002 10:57:59 -0400 X-Sybari-Trust: bd90cbed d3ce0cf3 84fb193b 0000093d From: Igor Fedorenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Re: controlling access to blocks References: <3D71A2FB.9080004@thinkdynamics.com> <200209011858.19660.peter@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2002 14:58:01.0756 (UTC) FILETIME=[F7CD3DC0:01C251C7] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ok, I will post a patch for cvs HEAD later this coming week. Btw, this stuff needs a little bit more from interceptor support then I originally thought. Specifically jaas interceptor must access BlockInfo somehow my guess through "Contextualizable" interface. It also needs to be Initializable/Startable. In other words, interceptors need lifecycle support as any other block (interceptor's lifecycle is couple with lifecycle of its block, so implementation might get tricky). Should I resubmit "interceptor patch" with this added functionality or should I wait for you to check interceptor support in and extend it after that? Peter Donald wrote: > Hiya, > > On Sun, 1 Sep 2002 15:17, Igor Fedorenko wrote: > >>I am finishing implementation of a coarse-grain access control for >>phoenix blocks and wonder if you are interesting in it. >> >>What I am doing is pretty much driven by current ejb approach (if I got >>it right :-) but with some simplifications. Basically, application >>developer associates methods of service interface (sic) with logical >>role or roles allowed to call the method. You could specify "unchecked" >>as well as have settings for "all other methods" and, of course, there >>is xdoclet support for all this. Application assembler maps logical >>roles into physical roles of environment using simple xml file and >>configures security interceptors for blocks (I still hope to see >>interceptors committed into the cvs :-). I have JAAS interceptor but >>other could be written easily. I still have some issues to resolve, like >>how to assign security context with calls originated from phoenix >>blocks, but otherwise I am almost there. The code lives in application >>space but could be migrated into phoenix kernel if you would like to >>adopt it. So, what do you think? > > > I think it sounds fantastic. I am still working on integrating the interceptor > stuff in. However I don't want to change too much at a time because of the > upcoming release. Maybe it may be time to branch for release purposes and > then we could keep applying your stuff to main tree where it wont effect the > release. That may be the best idea .... -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: For additional commands, e-mail: