Hi Rory, Rory Douglas schrieb: > When multiple AuthenticationHandlers are registered for a given path > prefix, the SlingAuthenticator tries each one in turn until one returns > an AuthenticationInfo object. There is no way to control the order in > which the handlers are tried.
Yes, this is true. We deliberately did not add such a functionality yet, in the intent to solve this problem as soon as it surfaces -- which seems to be the case now ;-) > > I suggest the AuthenticationHandler interface be extended to include > additional properties for controlling the order in which authentication > is attempted. I've implemented this with 2 new properties, Auth > Priority and Auth Challenge Priority. The first one controls the order > in which handlers are called for the authenticate() method. The second > controls the order for the requestAuthentication() method. > > Using 2 properties allows you to register both the HTTP Auth handler and > another (more interactive) handler simultaneously for the same set of > paths. The HTTP Auth handler is then assigned the highest "Auth > Priority". The interactive handler is assigned the highest "Auth > Challenge Priority". If a request is received containing BASIC Auth > credentials (i.e. from cURL/WebDAV), it is authenticated & the > interactive handler is not tried. If, however, there are no BASIC auth > credentials, the other handler is tried. If it too can't authenticate > the current request, the SlingAuthenticator will then attempt the > challenge process by calling requestAuthentication(). Here now, the > interactive handler is called first, which can then show a login form, > redirect to an SSO provider etc. This sounds reasonable to me. There is just one glitch if the client (cURL or WebDAV) is not preemptively sending the HTTP Basic credentials but is waiting for the challenge... Would need to be investigated, probably. What do you think ? > > I think this gives the behavior one would expect: cURL stills works fine > if you provide credentials, and users accessing Sling via the browser > get the custom login forms etc. > Another alternative would be to register Handlers with a Path and a > HostName. That way interactive handlers could be enabled only on > certain hostnames, so they wouldn't interfere with cURL or WebDAV. In fact, this is an interesting proposal in its own right with respect to the Virtual Host support we recently built into the ResourceResolver: You might argue, that I want to have different authentication methods for different virtual hosts. > > Thoughts? +1 ;-) Regards Felix
