incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Dahl <d...@goshawk.com>
Subject Re: Problem with custom Authorizers under JSPWiki 2.8.0
Date Thu, 22 Jan 2009 02:50:15 GMT
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.
>>


Mime
View raw message