Project

General

Profile

Actions

Bug #22204

closed

Projects & collections shared with groups causes errors

Added by Lucas Di Pentima about 1 month ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Story points:
-
Release:
Release relationship:
Auto

Description

Steps to reproduce:

  1. Create a test project or collection
  2. Open the Share dialog
  3. Share with "Anonymous users" or "All users" (or any other group)
  4. Click Save

Workbench will soon render a red toast with the message "You do not have access to share this item". This error toast will repeat when trying to open the Share dialog again. (I've attached a video demonstration)
Looking at the browser's network inspector it seems that workbench is doing a user's list request filtering by the group's UUID. The response is an 502 error.
This does not look like a Workbench bug, as I've checked that both 2.7.4 and main Workbenches do the same request, and also tested main Workbench against pirca and didn't got the error.


Files


Subtasks 1 (0 open1 closed)

Task #22213: Review 22204-group-sharingResolvedPeter Amstutz10/17/2024Actions

Related issues

Related to Arvados - Bug #22212: Improper user query federationNewActions
Actions #1

Updated by Lucas Di Pentima about 1 month ago

Here's the output when doing the same with the arv CLI:

lucasdipentima2@shell:~$ arv user list -c "none" -f '[["uuid", "in", ["tordo-j7d0g-anonymouspublic"]]]'
Error: request failed: https://jutro.arvadosapi.com/arvados/v1/users?cluster_id=&count=none&filters=%5B%5B%22uuid%22%2C%22in%22%2C%5B%22to
rdo-j7d0g-anonymouspublic%22%5D%5D%5D&limit=100&offset=0: 502 Bad Gateway: request failed: https://tordo.arvadosapi.com/arvados/v1/users?c
luster_id=&count=none&filters=%5B%5B%22uuid%22%2C%22in%22%2C%5B%22tordo-j7d0g-anonymouspublic%22%5D%5D%5D&forwarded_for=jutro-&include=&li
mit=100&offset=0: 401 Unauthorized: request failed: https://jutro.arvadosapi.com/arvados/v1/users?cluster_id=&count=none&filters=%5B%5B%22
uuid%22%2C%22in%22%2C%5B%22tordo-j7d0g-anonymouspublic%22%5D%5D%5D&forwarded_for=jutro-&limit=100&offset=0: 401 Unauthorized: //railsapi.i
nternal/arvados/v1/users?cluster_id=&count=none&filters=%5B%5B%22uuid%22%2C%22in%22%2C%5B%22tordo-j7d0g-anonymouspublic%22%5D%5D%5D&forwar
ded_for=jutro-jutro-&include=&limit=100&offset=0: 401 Unauthorized: Not logged in (req-1qhaiyjrrkmx1v1gag97)
lucasdipentima2@shell:~$ arv user list -c "none" -f '[["uuid", "in", ["jutro-j7d0g-anonymouspublic"]]]'                                   
{
 "items":[],
 "kind":"arvados#userList",
 "limit":100,
 "offset":0
}

The second (successful) try is asking for a jutro-based UUID instead of the local one.

Actions #2

Updated by Peter Amstutz about 1 month ago

So, this isn't exactly an invalid query but clearly controller's federated code path isn't behaving like it should.

However, I think we want to fix this in workbench, it shouldn't query the 'users' endpoint for uuids that are actually groups.

Actions #3

Updated by Peter Amstutz about 1 month ago

  • Assigned To set to Peter Amstutz
Actions #5

Updated by Peter Amstutz about 1 month ago

  • All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
    • no longer includes unnecessary elements in queries
  • Anything not implemented (discovered or discussed during work) has a follow-up story.
    • added a ticket to better handle the badly behaved query in controller: #22212
  • Code is tested and passing, both automated and manual, what manual testing was done is described.
    • tested manually on tordo, automated tests in process
  • New or changed UX/UX and has gotten feedback from stakeholders.
    • n/a
  • Documentation has been updated.
    • n/a
  • Behaves appropriately at the intended scale (describe intended scale).
    • should improve performance slightly by not making unnecessary queries and making the user/group queries in parallel
  • Considered backwards and forwards compatibility issues between client and server.
    • fixes the badly behaved query on the client instead of on the server, doesn't depend on any API changes
  • Follows our coding standards and GUI style guidelines.
    • yes

From the commit message:

  • Split user/group queries so we don't ask for groups from the user
    endpoint and vice versa
  • Make each query conditional on whether any permissions to users or
    groups were actually returned
  • Send user/group queries in parallel
  • Wrap the whole thing in try/finally to make sure it stops the
    loading spinner if there's an error
Actions #6

Updated by Peter Amstutz about 1 month ago

  • Related to Bug #22212: Improper user query federation added
Actions #7

Updated by Peter Amstutz about 1 month ago

  • Status changed from New to In Progress
Actions #9

Updated by Lucas Di Pentima about 1 month ago

Fix LGTM, although I wonder how difficult would it be to write/expand an e2e test to exercise this codepath?

Actions #10

Updated by Peter Amstutz about 1 month ago

Lucas Di Pentima wrote in #note-9:

Fix LGTM, although I wonder how difficult would it be to write/expand an e2e test to exercise this codepath?

I think the problem is this bug only shows up with federation.

Actions #11

Updated by Lucas Di Pentima about 1 month ago

Peter Amstutz wrote in #note-10:

Lucas Di Pentima wrote in #note-9:

Fix LGTM, although I wonder how difficult would it be to write/expand an e2e test to exercise this codepath?

I think the problem is this bug only shows up with federation.

Right! forgot about that detail, it's OK to merge then, thanks!

Actions #12

Updated by Peter Amstutz about 1 month ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF