incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching ...@ops.co.at>
Subject Re: Classmapping and final classes
Date Tue, 22 Jan 2008 15:18:52 GMT
Hi Andrew,

Andrew Jaquith schrieb:
> 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.
It would be great if it did work. But trying this I just get:

2008-01-22 15:47:47,598 ERROR [http-9151-2]
com.ecyrd.jspwiki.auth.AuthenticationManager - Could not log in.  Please
check that your jaas.config file is found.
java.lang.SecurityException: Anmeldekonfiguration kann nicht gefunden
werden.
        at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:93)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
        at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at
javax.security.auth.login.Configuration$3.run(Configuration.java:246)
        at java.security.AccessController.doPrivileged(Native Method)
        at
javax.security.auth.login.Configuration.getConfiguration(Configuration.java:241)
        at
javax.security.auth.login.LoginContext$1.run(LoginContext.java:237)
        at java.security.AccessController.doPrivileged(Native Method)
        at
javax.security.auth.login.LoginContext.init(LoginContext.java:234)
        at
javax.security.auth.login.LoginContext.<init>(LoginContext.java:367)
        at
javax.security.auth.login.LoginContext.<init>(LoginContext.java:444)
        at
com.ecyrd.jspwiki.WikiSession.getLoginContext(WikiSession.java:259)
        at
com.ecyrd.jspwiki.auth.AuthenticationManager$3.run(AuthenticationManager.java:441)
        at java.security.AccessController.doPrivileged(Native Method)
        at
com.ecyrd.jspwiki.auth.AuthenticationManager.doLogin(AuthenticationManager.java:435)
        at
com.ecyrd.jspwiki.auth.AuthenticationManager.login(AuthenticationManager.java:234)

Further up the stacktrace, we have passed through the acegi filter:
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
        at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
        at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)

For every page-access, a WikiContext object is created for the request.
This retrieves or creates a user-specific WikiSession object, and checks
the user login state.

>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.

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.

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...

Cheers,
Simon


Mime
View raw message