On Thu, Jul 1, 2010 at 11:40 AM, Emmanuel Lecharny <[email protected]>wrote:
> > > On Thu, Jul 1, 2010 at 10:37 AM, Kiran Ayyagari <[email protected]>wrote: > >> > I see your point. >> > Here, we have two options : >> > - merge the PP interceptor into the Athn interceptor (this is what you >> > propose) >> > - have the PP interceptor being processed after the authn, which is >> > possible. >> > The question is more or less about the PP being a part of the authent >> > process, or if we want to have a separate module just to have a distinct >> > processing for the PP (this could make sense if we want to disable the >> PP). >> > The reason why the PP interceptor is separate atm is that it was not >> present >> > at the origin, and was added after. The Intecreptor chain allows us to >> have >> > such a separation, and it was easy to add featuers this way. >> > Now, I'm not sure it makes sense to make a distinction between the PP >> and >> > auth interceptrs at this point, if we consider that PP is a part of the >> > server (ie, it can't be disabled). >> >> disabling PP is done based on the configuration, so it is not >> intrusive. If the PP configuration >> is not provided then the AuthenticationInterceptor skips all checks >> related to PP. >> > > That's fine. > > I'm not sure we want to disable the PP anyway :) As I said, it was made an > interceptor for historical reasons, and I do think it must be part of the > server anyway - even if no policy is set :) > > OK if there is a null policy to offer the present lack of PP then I guess it makes no difference to which way we go: PP interceptor or merged functionality into the AuthN interceptor. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
