Steve, I've committed a fix to the 2.8 trunk. If you check out the
latest 2.8 build from SVN, you'll be able to obtain the fix.
Could you test out the latest 2.8 trunk build? So that we can keep
track of everything, please use the JIRA bug tracker for additional
comments and questions related to this bug:
https://issues.apache.org/jira/browse/JSPWIKI-473
Thanks -- let's see if this works for you. (It should.)
Andrew
On Jan 21, 2009, at 9:50 PM, Steve Dahl wrote:
I still haven't worked through this yet, but simply changing my
Authorizer to implement WebAuthorizer, and changing
isContainerAuthorized() to return true, doesn't seem to solve the
problem. I changed the logging level to DEBUG, and I don't see the
debug messages that WebContainerLoginModule.login() is supposed to
write. My Authorizer apparently is never asked to getRoles(). But
I'm still looking...
Yes, I'd be happy to help test any changes you want to send my way.
Not having to mix in WebAuthorizer seems like a cleaner way to
handle our problem.
Andrew R Jaquith wrote:
Steve --
Sorry for the delay in my reply. The end-of-year and holiday have
meant that I haven't been able to do as much work on JSPWiki in the
last few weeks.
Looking a bit into the code, in 2.8, it turns out that the code
that looks for container roles moved to WebContainerLoginModule. It
calls isUserInRole( HttpServletRequest, Principal ), and not the
WikiSesson version. That explains why your roles aren't being added
to the user's Principal list. Thus, in the short term, you need to
implement WebAuthorizer in order to make your Authorizer work.
That said, I recognize that the technique we use in 2.8 is causing
your custom Authorizer to fail, and as such I'd have to call it a
bug. Implementing Authorizer should have been sufficient, you
should not have to implement WebAuthorizer.
We would have caught this if we had a unit test for custom
authorizers, but we don't. I will fix this -- both the bug, and
lack of tests for custom authorizers -- in the next maintenance
release of 2.8. I hope to have the fix in the 2.8 trunk into the
next week or two.
In the meantime, I'd like to enlist your help in the fix. Once I
get a fix committed, could you test it out with your Authorizer?
Andrew
On Dec 22, 2008, at 3:54 PM, Steve Dahl wrote:
Steve Dahl wrote:
Under JSPWiki 2.6.4, we've replaced WebContainerAuthorizer with
an LDAPAuthorizer which implements JSPWiki roles in terms of LDAP
groups.
When I compile this for JSPWiki 2.8.0, and modify the
jspwiki.properties file to use it, our custom LDAPAuthorizer gets
initialized, and is sent findRole(), but it never seems to get
sent isUserInRole().
If it's useful information, LDAPAuthorizer implements Authorizer
(not WebAuthorizer), and it implements isUserInRole() with this
signature:
public boolean isUserInRole( WikiSession session, Principal role )
Is there anything that has changed in Authorizers between 2.6.4
and 2.8.0 that might explain this?
Looking deeper, it seems that in JSPWiki 2.6.X, WikiSession
implemented injectRolePrincipals(), which initialized the session
with whatever groups and roles the user belongs to. Groups are
read from the group database, and Roles are read from the
Authorizer.
In JSPWiki 2.8.X, injectRolePrincipals() has been replaced by
injectGroupPrincipals(), which reads groups from the group
database but doesn't use the Authorizer. What is the Authorizer
used for now?
As a side note, I originally implemented LDAPAuthorizer as
LDAPGroupDatabase. I ended up rejecting this approach because
GroupManager assumes that the members of a Group can be read once
when the Wiki is started, and that the Group's membership will
only be modified by the Wiki. The problem with LDAP is that the
group membership can be modified from outside, and the only way to
update the wiki would be to manually restart it. The Authorizer
was a better solution for our purposes, because if a user was
added to the LDAP group, the Authorizer would reflect that change
as soon as the user logged out and back in. Restarting the wiki is
not necessary.
