tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28286] - Loosely couple SingleSignOn Valve and Authenticators
Date Mon, 26 Apr 2004 05:48:16 GMT
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 b_stansberry@hotmail.com  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message