DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28286>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28286 Loosely couple SingleSignOn Valve and Authenticators ------- Additional Comments From [EMAIL PROTECTED] 2004-04-26 05:48 ------- I thought you might feel that way about the 28039 patch, which is one reason why I wrote the interface proposal ;-) And, it's true an interface isn't absolutely needed; subclassing would work. The fact that SingleSignOnEntry is not public (and I'm not arguing it should be) is a big stumbling block in easily subclassing SingleSignOn, but getting around that problem in a subclass is no harder than writing a whole new implementation of an interface. But, to get subclassing to work effectively, a couple things need to be changed: 1) AuthenticatorBase.reauthenticateFromSSO() invokes SingleSignOn.lookup(). This method returns a SingleSignOnEntry, which is a package protected class. This effectively precludes subclassing this method. 2) SingleSignOn.update() is package protected, again preventing subclassing. I'm attaching another patch that addresses these two issues by: 1) Changing the way AuthenticatorBase.reauthenticateFromSSO() works so it does not need to call SingleSignOn.lookup(). lookup() is now only called internally in SingleSignOn, so someone who wished to write a subclass could just remove any calls to it, write their own lookup algorithm, and replace SingleSignOnEntry with their own class. 2) Makes SingleSignOn.update() protected. Maybe 3rd time's the charm? ;-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
