On Thu, Jul 1, 2010 at 11:40 AM, Emmanuel Lecharny <elecharny@apache.org> wrote:


On Thu, Jul 1, 2010 at 10:37 AM, Kiran Ayyagari <kayyagari@apache.org> 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