Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8, 2.8.1
    • Fix Version/s: 2.8.2, 3.0
    • Labels:
      None
    • Environment:

      All

      Description

      From the jspwiki-dev list:

      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.

        Activity

        Hide
        Andrew Jaquith added a comment -

        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.

        Show
        Andrew Jaquith added a comment - 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.
        Hide
        Andrew Jaquith added a comment -

        Fix committed in 2.8.1-build 5.

        Show
        Andrew Jaquith added a comment - Fix committed in 2.8.1-build 5.
        Hide
        Janne Jalkanen added a comment -

        How about 3.0?

        Show
        Janne Jalkanen added a comment - How about 3.0?
        Hide
        Andrew Jaquith added a comment -

        Yes, I will forward-port this to 3.0 once Steve indicates that the fix actually works.

        Show
        Andrew Jaquith added a comment - Yes, I will forward-port this to 3.0 once Steve indicates that the fix actually works.
        Hide
        Steve Dahl added a comment -

        Sorry for the delay.

        I don't understand how much of this is my own unfamiliarity with compiling JSPWiki from source and how much is a real problem in the code, but things seem to have gotten worse. I downloaded the sources from:

        http://svn.eu.apache.org/repos/asf/incubator/jspwiki/branches/JSPWIKI_2_8_BRANCH

        ...and the ChangeLog file in my download says that the version is 2.8.2-svn-9.

        When I build and install this, it seems to disable all access controls. I have one page whose ACL reads:

        [

        {ALLOW modify TechD}

        ]
        [

        {ALLOW view Authenticated}

        ]
        [

        {ALLOW rename TechD}

        ]

        But when I visit this page without logging in, I am allowed to view it and edit it. If I log in as a user that does not belong to the TechD role, I am also allowed to view and edit it.

        Show
        Steve Dahl added a comment - Sorry for the delay. I don't understand how much of this is my own unfamiliarity with compiling JSPWiki from source and how much is a real problem in the code, but things seem to have gotten worse. I downloaded the sources from: http://svn.eu.apache.org/repos/asf/incubator/jspwiki/branches/JSPWIKI_2_8_BRANCH ...and the ChangeLog file in my download says that the version is 2.8.2-svn-9. When I build and install this, it seems to disable all access controls. I have one page whose ACL reads: [ {ALLOW modify TechD} ] [ {ALLOW view Authenticated} ] [ {ALLOW rename TechD} ] But when I visit this page without logging in, I am allowed to view it and edit it. If I log in as a user that does not belong to the TechD role, I am also allowed to view and edit it.
        Hide
        Janne Jalkanen added a comment -

        So can we consider this fixed fo 2.8 or not? Andrew?

        Show
        Janne Jalkanen added a comment - So can we consider this fixed fo 2.8 or not? Andrew?
        Hide
        Janne Jalkanen added a comment -

        Steve? Andrew? Anyone? Does the fix work?

        Show
        Janne Jalkanen added a comment - Steve? Andrew? Anyone? Does the fix work?
        Hide
        Janne Jalkanen added a comment -

        OK, so I am marking this one resolved since there's no comment about it. Please mark it closed if you're satisfied it's fully fixed.

        Show
        Janne Jalkanen added a comment - OK, so I am marking this one resolved since there's no comment about it. Please mark it closed if you're satisfied it's fully fixed.
        Hide
        Andrew Jaquith added a comment -

        Closing this issue; our unit tests check to make sure this works as it should.

        If, after additional testing, Steve determines that this fix has not solved his issue, we will re-open... assuming the root cause isn't something else.

        Show
        Andrew Jaquith added a comment - Closing this issue; our unit tests check to make sure this works as it should. If, after additional testing, Steve determines that this fix has not solved his issue, we will re-open... assuming the root cause isn't something else.

          People

          • Assignee:
            Andrew Jaquith
            Reporter:
            Andrew Jaquith
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development