Adding the new method for 1.3 is difficult: while not backwards compatible, it is certainly better than changing the behavior of an existing API. But if we want to guarantee APR versioning guidelines - which reinforces perceived stability (highly desirable for a security API/framework) - it should probably go into 2.x only.
If we are to guarantee backwards compatibility, a new strategy should be implemented that throws an Exception from the afterAttempt method. That exception is inspected (e.g. ShortCircuitIterationException) to trigger whether or not to continue to further realms. Yes, this is hacky, yes, it's not ideal, but it does guarantee backwards compatibility while still retaining existing functionality. Because I favor stability in a security framework, my preference is to do the hacky exception approach and then clean this up permanently in 2.x. But I could be in the minority here. What are peoples' thoughts on this? Les On Fri, Mar 9, 2012 at 9:56 AM, Brian Demers <[email protected]> wrote: > The ModularRealmAuthenticator always loops through all the configure > realms. This can get expense if you have multiple external realms > configured (JDBC, LDAP, etc), and you are using > the FirstSuccessfulStrategy. In this case where you had both a JDBC and > LDAP realm configured you would want to drop out of the loop if the Subject > was authenticated in the JDBC realm. This way you do not need to eat the > cost of the LDAP query (which the results would be ignored anyway) > > To solve this I added a new method to the AuthenticationStrategy Interface, > this makes the change simple, but would break backwards compatibility with > any custom AuthenticationStrategy NOT extending from > AbstractAuthenticationStrategy. > https://github.com/apache/shiro/compare/trunk...first-successful-authc-strategy#L1R99 > > I cannot think of any (non hackie way) alternative to this for 1.3. Anyone > have any thoughts? Or any thoughts on including this in 1.3?
