> While looking at the CredentialValidator patch by Mike > (SLING-1593 [1]) > I came across the Authentication Info post processor infrastructure > introduced by Justin (SLING-1444 [2]). > > Now, I am bit worried of having two mechanisms with different services > basically doing the same thing: Take an AuthenticationInfo > object check, > add, modify, remove properties (and return the object). > > Isn't this the same ? Do we really need two mechanism for > almost the same ?
At least we can solve the use cases I mentioned for CredentialsValidator. I haven't came across the SLING-1444 before either. > How about a generic processor for credentials which is called after > extracting the credentials from the request but before the credentials > are provided to the ResourceResolverFactory. > > We could enhance this by allowing the processor to reject the > credentials thus aborting early. > > WDYT ? > > Thanks and Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-1593 > [2] https://issues.apache.org/jira/browse/SLING-1444 One of the ideas for CrednetialsValidator was to better separate authentication into different parts, like 1) extract the credentials 2) validate the credentials 3) get the resource resolver But I agree with Felix, that it doesn't make sense to have two different implementations which nearly do the same. That would also mean to document and maintain both approaches. So my suggestion is to make a tiny enhancement to the AuthenticationInfoPostProcessor and to abandon my patch with the CredentialsValidator. I would let the postProcess method throw an exception in which case Sling should abort the request dispatching. Because in this case AuthenticationInfoPostProcessor is much more generic than the CrednetialsValidator (which should only validate credentials) Sling can't handle the Exception in a predefined manner, that means the AuthenticationInfoPostProcessor has to forward to a login or whatever in case of en error. best regards mike
