incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
Subject Re: Classmapping and final classes
Date Tue, 22 Jan 2008 13:31:08 GMT
I think there is a much easier solution here. JSPWiki's JAAS stack  
will automatically pick up and login credentials that are populated in  
the HttpServletRequest. My understanding about how ACEGI is that,  
using a filter, it wraps the request with its own wrapper class and  
returns the authenticated Principal via (wrapper) 
ServletRequest.getUserPrincipal/getRemoteUser.

JSPWiki has always been designed to work in a scenario like this. You  
shouldn't need to write a line of code. All you'd need to do is make  
sure the ACEGI filter executes before JSPWiki's own.

I don't have hands-on experience with ACEGI but I think that's how to  
do it.

Andrew

On Jan 22, 2008, at 7:59, Murray Altheim <murray06@altheim.com> wrote:

> Simon Kitching wrote:
> [...]
>> Thanks very much for your time Murray.
>
> Hi Simon,
>
> You're quite welcome.
>
>> However I am still reasonably sure that the final status of the
>> AuthorizationManager *is* a problem (and I have been doing this Java
>> thing for a few years now).
>
> I certainly didn't mean to imply otherwise.
>
>> Let's split up the code in WikiEngine into steps:
>> (1) String reqClass = AuthenticationManager.class.getName();
>> (2) Object mgrObj = ClassUtil.getMappedObject(reqClass);
>> (3) m_authenticationManager = (AuthenticationManager) mgrObj;
>> Steps (1) and (2) are fine. Yes, it is possible to configure the
>> classmappings.xml file to point to my custom implementation, and
>> ClassUtil will happily load the Class, create an instance and  
>> return it.
>> No problems here at all.
>> But in (3), the attempt to cast the custom object to type
>> com.eycrd.wiki.auth.AuthenticationManager will fail because it is  
>> not of
>> that type. A ClassCastException will therefore occur and the  
>> WikiEngine
>> will fail to initialise.
>> The solution is simply to make the custom class subclass
>> AuthenticationManager - but that is not possible because that class  
>> is
>> final.
>
> Yes, understood, I see your point now. It sounds like  
> AuthenticationManager
> needs to be an API in order for this to work. Sorry to not see this  
> problem
> earlier.
>
>> Note that I've now got a solution that works for me; I have a  
>> custom jar
>> with a reimplementation of the problem classes (without final
>> qualifiers) and I have named the jar "_jspwiki_patch.jar", where the
>> leading underscore causes the servlet engine picks it up before the  
>> real
>> JSPWiki.jar (alphabetical order). But sometime it might be nice to
>> either fix this in the jspwiki code or rip out the
>> ClassUtils.getMappedObject calls and just replace them with "new"..
>
> Well, unless this is a common use case (which it might be, dunno),  
> it's
> probably better that you have simply rewritten the 'problem'  
> classes. If
> this is something Andrew thinks is a good idea (and he's certainly the
> expert on security more than myself) then perhaps looking into  
> rewriting
> AuthenticationManager and AuthorizationManager as interfaces might  
> be in
> order for the future.
>
> Cheers,
>
> Murray
>
> ... 
> ... 
> .....................................................................
> Murray Altheim <murray07 at altheim.com>                            
> ===  = =
> http://www.altheim.com/murray/                                     =  
> =  ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               =  
> =  = =
>
>      Boundless wind and moon - the eye within eyes,
>      Inexhaustible heaven and earth - the light beyond light,
>      The willow dark, the flower bright - ten thousand houses,
>      Knock at any door - there's one who will respond.
>                                      -- The Blue Cliff Record

Mime
View raw message