Uploaded image for project: 'DSpace (LEGACY)'
  1. DSpace (LEGACY)
  2. DS-4534

grant access to Anonymous as a subgroup

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 6.3, 7.0
    • Fix Version/s: 6.4, 7.0
    • Component/s: DSpace API
    • Labels:
      None
    • Environment:
      Linux w/ Tomcat, Oracle JDK 8, XMLUI
    • Attachments:
      0
    • Comments:
      2
    • Documentation Status:
      Not Required

      Description

      When we grant 'Anonymous' READ to item's bitstream by granting READ access to group A, which has Anonymous as a sub-group, the unathenticated user does not receive the privilege.

      This used to be work in 5.9, and after upgrading to version 6.3, it stopped working.

      We have several item's bitstreams where a group has been added to them as a policy. These groups contain the group 'Anonymous' as the only sub-group of them. The rationale behind this is that we can add or remove the ANonymous access by editing the group A rather than editing item policy assigmnments.

      We have discovered that this is the case only when we add the group 'Anonymous' to an existing group as a sub-group.

      After a little investigation we found that the function 'isMember' never handles the above situation. If the item contains the 'Anonymous' group directly then it returns true (line 178) but there are no any other place to check whether the given group contains the 'Anonymous' or not.

      https://github.com/DSpace/DSpace/blob/acf16ebe6dc69e5d8c823797a8da402ef932cc18/dspace-api/src/main/java/org/dspace/eperson/GroupServiceImpl.java#L177-L179

      A fix has been found by adding an 'isParentOf' call to the else if statement like this:

      {{

      else if (StringUtils.equals(group.getName(), Group.ANONYMOUS) || isParentOf(context, group, findByName(context, Group.ANONYMOUS)))
      }}

      Even if this fix solved our issue temporarily, we would like to know if this change in behavious is intentional or a bug? I mean was it a business decision to skip checking the Anonymous group as a sub-group within the authorization process? If yes, what is the preferred way to implement the access model described above?

      By inspecting the source code, we think that this problem also affects the master branch:

      https://github.com/DSpace/DSpace/blob/338bb2296f5eb766a2eff83d61f83a0676232d92/dspace-api/src/main/java/org/dspace/eperson/GroupServiceImpl.java#L191-L193

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jmarton Jozsef Marton
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: