geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Question about default subject in tomcat integration
Date Wed, 04 Jan 2006 23:22:39 GMT

On Jan 4, 2006, at 2:49 PM, Jeff Genender wrote:

> DJ,
>
> Didn't you write the DefaultSubjectValve? ;-)

That was three months ago! How do you expect me to remember such  
ancient history ??? :-)

So, it looks to me as if GERONIMO-1012 was, as I thought, not  
complete and you shouldn't have closed it :-)

Will continue investigating.  Do you know of any way to install a  
valve AFTER the ones tomcat installs for you, or a way to change what  
those valves are?  I think putting the DefaultSubjectValve after the  
authentication happens would fix the problems.

thanks
david jencks

>
> Jeff
>
> David Jencks wrote:
>> In GeronimoStandardContext this is the code that sets up the
>> DefaultSubjectValve:
>>
>>                 //This is definitely a hack, but I don't see a
>> reasonable way to install the defaultSubject.
>>                 //Obviously this won't work if there are permissions.
>> Setting the default subject if there are
>>                 //permissions breaks authentication.
>>                 boolean hasPermissions =
>> securityHolder.getChecked().elements().hasMoreElements() ||
>>
>> securityHolder.getExcluded().elements().hasMoreElements();
>>                 Valve defaultSubjectValve;
>>                 if (!hasPermissions && defaultSubject != null) {
>>                     defaultSubjectValve = new
>> DefaultSubjectValve(defaultSubject);
>>                 } else {
>>                     //this will clear the thread of any read subject
>> added by some other web app
>>                     defaultSubjectValve = new DefaultSubjectValve 
>> (null);
>>                 }
>>                 addValve(defaultSubjectValve);
>>
>>
>> In DefaultSubjectValve, the operative code is:
>>
>>     public void invoke(Request request, Response response) throws
>> IOException, ServletException {
>>         boolean setSubject = ContextManager.getCurrentCaller() ==  
>> null;
>>         if (setSubject) {
>>             ContextManager.setCurrentCaller(defaultSubject);
>>             ContextManager.setNextCaller(defaultSubject);
>>             try {
>>                 getNext().invoke(request, response);
>>             } finally {
>>                 ContextManager.setCurrentCaller(null);
>>                 ContextManager.setNextCaller(null);
>>             }
>>         } else {
>>             getNext().invoke(request, response);
>>         }
>>     }
>>
>>
>> This doesn't make any sense to me.  If
>> DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve
>> will clear nextCaller if currentCaller is null, otherwise do  
>> nothing.  I
>> doubt this is critical functionality.  However, it appears to me that
>> the code in GeronimoStandardContext that sets
>> DefaultSubjectValve.defaultSubject to null if the web app has checked
>> constraints appears to me to prevent the default subject from  
>> being set
>> for that portion of the app that is unsecured, which is where I  
>> thought
>> it was important.
>>
>> Could someone explain just how always using the actual defaultSubject
>> breaks authentication?
>>
>> thanks
>> david jencks


Mime
View raw message