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 16:46:06 GMT
Simon -- see my comments below.

> From the WikiContext constructor:
>
>        // Log in the user if new session or the container status  
> changed
>        boolean doLogin = (request != null) && m_session.isNew();
>
>        if( doLogin || m_session.isContainerStatusChanged( request ) )
>        {
>            try
>            {
>                engine.getAuthenticationManager().login( request );
>            }
>            catch ( WikiSecurityException e )
>            {
>                // Login failed because config was screwy
>                log.error( "Could not log in user: " +  
> e.getMessage() );
>            }
>        }
>
>
> So here there is no attempt from jspwiki code to see whether there  
> is a
> UserPrincipal in the current request; it just calls the login method  
> on
> the AuthenticationManager whenever WikiSession.isNew returns true, ie
> the first time a particular user accesses the wiki.

Not quite right. It will also invoke the JAAS login process if   
isContainerStatusChanged() returns true, which it will if the remote  
user, user princpal, or "assertion cookie" changes to some non-null  
value. That will happen if and when ACEGI populates these values. So  
I'd say the basic problem is that JSPWiki can't locate its JAAS config.

> The AuthenticationManager.login call eventually ends up at
>  WikiSession.getLoginContext
> which does:
>   return new LoginContext( application, m_subject, handler );
> where LoginContext is a javax.security class. And that eventually  
> fails
> to "initialise" the jaas system - which of course it will, because we
> are not using the build-in jaas, but ACEGI instead.

Well, in this case what JSPWiki depends on is being able to find its  
JAAS login configuration, called "JSPWiki-container". This stack  
executes so that JSPWiki can pick up the container principal/remote  
user. That's going to be true REGARDLESS of whether or not you use  
ACEGI. So, put simply, JSPWiki must be able to find this  
configuration. It's clearly not finding it in your case.

If ACEGI configures its own JAAS stack, then what you should do is  
append the contents of jspwiki.jaas to it. That way, JSPWiki will be  
able to find the correct login configuration. Then the login stack  
will execute as we expect, and JSPWiki will be able to detect the  
credentials ACEGI is passing.

> I don't know where the "bug" might be here; whether it is my ACEGI
> config or the way jspwiki uses javax.security or anything else. It's
> well beyond my knowledge at this point :-(.
>
> If anyone has a suggestion I'd be glad to try it (and report back),  
> but
> otherwise I'll keep on with a custom AuthenticationManager...

You are welcome to do whatever you like, but at this point I'd say  
this falls squarely into the realm of configuration, not programming.

>
>
> Cheers,
> Simon
>


Mime
View raw message