Bug #22204
closed
Projects & collections shared with groups causes errors
Added by Lucas Di Pentima about 1 month ago.
Updated about 1 month ago.
Release relationship:
Auto
Description
Steps to reproduce:
- Create a test project or collection
- Open the Share dialog
- Share with "Anonymous users" or "All users" (or any other group)
- 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
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.
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.
- Assigned To set to Peter Amstutz
- 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.
- Documentation has been updated.
- 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.
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
- Related to Bug #22212: Improper user query federation added
- Status changed from New to In Progress
Fix LGTM, although I wonder how difficult would it be to write/expand an e2e test to exercise this codepath?
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.
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!
- Status changed from In Progress to Resolved
Also available in: Atom
PDF