Uploaded image for project: 'XNAT'
  1. XNAT
  2. XNAT-5925

Improper caching of data access when user added to project

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.7.5.1
    • Fix Version/s: 1.7.5.2
    • Component/s: None
    • Sprint:
      1.7.5.2 Point release
    • Rank:
      0|ii1nlz:
    • Sprint:
      1.7.5.2 Point release

      Description

      Consider the case that a user registers to an XNAT site, is approved by the admin, logs in, requests access to a project, is granted access. This is a fairly common use case and should work correctly. In 1.7.5.1, there are all sorts of UI issues, such as the user not being able to add experiments, and getting errors on the project page (and being unable to view the users on the project even if they were granted owner access). There are a variety of ways of triggering this bug (and I found it because everything was buggy after I tried giving my CNDA account access to a project so I could work on another issue), such as the steps described in detail below.

      After Mike ran into an issue similar to XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 1.7.5.1:

      1. As an admin, create a new user.
      2. Strange, but important: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
      3. Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
      4. Log back out.
      5. Login as the new user. Do the REST calls to: /xapi/access/displays/browseableCreateable and /xapi/access/displays/browseable. It returns an empty array for both, which is NOT correct (the list should include at least the MR session data type).
      6. Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
      7. If you repeat the REST calls again, they STILL return empty lists (!!!!)
      8. If you then create a project as this user, the REST call populates with the expected data types.

      Note that the incorrectly cached values will cause (non-exhaustive):

      1. No data types show up on advanced search.
      2. New > Experiment list of data types is empty.
      3. Browse > Data top nav UI element does not display.

        Issue Links

          Activity

          moore.c@wustl.edu Charlie Moore created issue -
          moore.c@wustl.edu Charlie Moore made changes -
          Field Original Value New Value
          Link This issue relates to XNAT-5922 [ XNAT-5922 ]
          mfmckay@wustl.edu Mike McKay (Inactive) made changes -
          Description After Mike ran into an issue similar to XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 1.7.5.1:
          # As an admin, create a new user.
          # *Strange, but important*: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
          # Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
          # Log back out.
          # Login as the new user. Do the REST calls to: {{/xapi/access/displays/browseableCreateable}} and {{/xapi/access/displays/browseable}}. It returns an empty array for both, which is *NOT* correct (the list should include at least the MR session data type).
          # Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
          # If you repeat the REST calls again, they *STILL* return empty lists (!!!!)
          # If you then create a project as this user, the REST call populates with the expected data types.

          Note that the incorrectly cached values will cause (non-exhaustive):
          # No data types show up on advanced search.
          # New > Experiment list of data types is empty.
          # Browse > Data top nav UI element does not display.
          Consider the case that a user registers to an XNAT site, is approved by the admin, logs in, requests access to a project, is granted access. This is a fairly common use case and should work correctly. In 1.7.5.1, there are all sorts of UI issues, such as the user not being able to add experiments, and getting errors on the project page (and being unable to view the users on the project even if they were granted owner access). There are a variety of ways of triggering this bug, such as the steps described in detail below.

          After Mike ran into an issue similar to XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 1.7.5.1:
          # As an admin, create a new user.
          # *Strange, but important*: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
          # Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
          # Log back out.
          # Login as the new user. Do the REST calls to: {{/xapi/access/displays/browseableCreateable}} and {{/xapi/access/displays/browseable}}. It returns an empty array for both, which is *NOT* correct (the list should include at least the MR session data type).
          # Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
          # If you repeat the REST calls again, they *STILL* return empty lists (!!!!)
          # If you then create a project as this user, the REST call populates with the expected data types.

          Note that the incorrectly cached values will cause (non-exhaustive):
          # No data types show up on advanced search.
          # New > Experiment list of data types is empty.
          # Browse > Data top nav UI element does not display.
          mfmckay@wustl.edu Mike McKay (Inactive) made changes -
          Priority Critical [ 2 ] Blocker [ 1 ]
          mfmckay@wustl.edu Mike McKay (Inactive) made changes -
          Description Consider the case that a user registers to an XNAT site, is approved by the admin, logs in, requests access to a project, is granted access. This is a fairly common use case and should work correctly. In 1.7.5.1, there are all sorts of UI issues, such as the user not being able to add experiments, and getting errors on the project page (and being unable to view the users on the project even if they were granted owner access). There are a variety of ways of triggering this bug, such as the steps described in detail below.

          After Mike ran into an issue similar to XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 1.7.5.1:
          # As an admin, create a new user.
          # *Strange, but important*: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
          # Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
          # Log back out.
          # Login as the new user. Do the REST calls to: {{/xapi/access/displays/browseableCreateable}} and {{/xapi/access/displays/browseable}}. It returns an empty array for both, which is *NOT* correct (the list should include at least the MR session data type).
          # Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
          # If you repeat the REST calls again, they *STILL* return empty lists (!!!!)
          # If you then create a project as this user, the REST call populates with the expected data types.

          Note that the incorrectly cached values will cause (non-exhaustive):
          # No data types show up on advanced search.
          # New > Experiment list of data types is empty.
          # Browse > Data top nav UI element does not display.
          Consider the case that a user registers to an XNAT site, is approved by the admin, logs in, requests access to a project, is granted access. This is a fairly common use case and should work correctly. In 1.7.5.1, there are all sorts of UI issues, such as the user not being able to add experiments, and getting errors on the project page (and being unable to view the users on the project even if they were granted owner access). There are a variety of ways of triggering this bug (and I found it because everything was buggy after I tried giving my CNDA account access to a project so I could work on another issue), such as the steps described in detail below.

          After Mike ran into an issue similar to XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 1.7.5.1:
          # As an admin, create a new user.
          # *Strange, but important*: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
          # Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
          # Log back out.
          # Login as the new user. Do the REST calls to: {{/xapi/access/displays/browseableCreateable}} and {{/xapi/access/displays/browseable}}. It returns an empty array for both, which is *NOT* correct (the list should include at least the MR session data type).
          # Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
          # If you repeat the REST calls again, they *STILL* return empty lists (!!!!)
          # If you then create a project as this user, the REST call populates with the expected data types.

          Note that the incorrectly cached values will cause (non-exhaustive):
          # No data types show up on advanced search.
          # New > Experiment list of data types is empty.
          # Browse > Data top nav UI element does not display.
          moore.c@wustl.edu Charlie Moore made changes -
          Labels cnda-interest
          moore.stephen.m@wustl.edu Steve Moore made changes -
          Assignee Rick Herrick [ rherri01 ]
          moore.stephen.m@wustl.edu Steve Moore made changes -
          Labels cnda-interest cnda-interest fix-asap
          Hide
          gkgurney@wustl.edu Jenny Gurney added a comment -

          This may have all been caused by the corrupt hash indexes. Please retry on a fresh CNDA VM. Thanks!

          Show
          gkgurney@wustl.edu Jenny Gurney added a comment - This may have all been caused by the corrupt hash indexes. Please retry on a fresh CNDA VM. Thanks!
          Hide
          mfmckay@wustl.edu Mike McKay (Inactive) added a comment -

          Just to note in case it was unclear, we had already recreated this issue on non-CNDA 1.7.5.1 XNATs, so I see no reason to think it would now work on a fresh CNDA VM. Not that we can't test, but I wouldn't be comfortable setting this one aside until the core XNAT issue is fixed.

          Show
          mfmckay@wustl.edu Mike McKay (Inactive) added a comment - Just to note in case it was unclear, we had already recreated this issue on non-CNDA 1.7.5.1 XNATs, so I see no reason to think it would now work on a fresh CNDA VM. Not that we can't test, but I wouldn't be comfortable setting this one aside until the core XNAT issue is fixed.
          moore.stephen.m@wustl.edu Steve Moore made changes -
          Sprint 1.7.5.2 Point release [ 135 ]
          jrherrick@wustl.edu Rick Herrick logged work - 04/Feb/19 3:44 PM
          • Time Spent:
            3 hours
             

            Added more info to group update events. Now the cache clears and regenerates user cache entries when group memberships are updated.

          jrherrick@wustl.edu Rick Herrick made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          jrherrick@wustl.edu Rick Herrick added a comment -

          Added more info to group update events. Now the cache clears and regenerates user cache entries when group memberships are updated.

          Show
          jrherrick@wustl.edu Rick Herrick added a comment - Added more info to group update events. Now the cache clears and regenerates user cache entries when group memberships are updated.
          jrherrick@wustl.edu Rick Herrick made changes -
          Worklog Id 17436 [ 17436 ]
          Time Spent 3 hours [ 10800 ]
          Remaining Estimate 0 minutes [ 0 ]
          jrherrick@wustl.edu Rick Herrick made changes -
          Resolution Fixed [ 1 ]
          Assignee Rick Herrick [ rherri01 ] Charlie Moore [ cmoore01 ]
          Fix Version/s 1.7.5.2 [ 14722 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          moore.c@wustl.edu Charlie Moore made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              moore.c@wustl.edu Charlie Moore
              Reporter:
              moore.c@wustl.edu Charlie Moore
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 3 hours
                3h

                  Agile