Permissions on Entity Pages: View + Download buttons

rosibaj commented 3 years ago

Which users can see the page? Which users can download a file?

Entity pages are subject to access control:

For any entity page need to access the API to find out the permissions
API Response should be access (i.e data returned) OR Not found
If found, the file page should load data..
If not found, the page should say "not found". The file page should load (not crash) but say file not found.
[ ] Verify that the API returns this response correctly (empty response if no access to the file). We think that file responses. ARE filtered by permission.
[ ] If the file is access.controlled, and the file size is < 1gb , and the user must have DACO.read to be enabled. (tooltip over 1gb)

FOR Rosi's testing:

[ ] If user not logged in, and the file.access is open the downloads button is enabled.
[ ] If user not logged in, and the file.access is controlled the downlead button is disabled.
[ ] If user is logged in, and the file.access is controlled, and the user has DACO, then the downlead button is enabled.

ciaranschutte commented 3 years ago

@rosibaj

our generic 404 not found page or a specific "file entity not found" page?
If the file is access.controlled, and the file size is < 1gb , and the user must have DACO.read to be enabled. (tooltip over 1gb) - does this imply that if it's under 1gb and is controlled there is no DACO check?
Verify that the API returns this response correctly (empty response if no access to the file). are the permissions based on release_stage? Just need to know what I need to edit for testing this.

ciaranschutte commented 3 years ago

@kcullion just looping you in here because you're the design hero. ^

kcullion commented 3 years ago

@ciaranschutte @rosibaj maybe this 401 page would cover it? https://zpl.io/aBKd1l0 Maybe in this case it could also say, or login if you have program access (if we want to customize that)

NOte: this page has already been built

rosibaj commented 3 years ago

@ciaranschutte sorry i missed your comment before.

generic page is fine
no, that does not imply that . i will extende that list with this item to be more clear: If user is logged in, and the file.access is controlled, and the user does NOT have DACO, then the downlead button is disabled.
yes, permissions are based on release stage and progam scope permissions (same as the file repository filters)

kcullion commented 3 years ago

@rosibaj just to clarify, they will only see links to the file entity pages in the file repo table that they have access to right? So they only see this 401 page if they logout and go to that link?

rosibaj commented 3 years ago

@ciaranschutte @kcullion ive confirmed wiht Jon, we should show the 404 UI page in this case.

@kcullion to answer your question, yes a user should only see links for files they can access. this would happen if

a user with permission to a file page is logged in then logs out
a user sends a file link to someone that does not have permissions
someone manually formats a file url and happens upon a real file id

We don't want to show a 401 authorization page, as this this file shouldnt "exist" for a user that doesn't have permission. in the case of crawling for ids, this would give information away we dont want to and the 404 is the right choice to prevent that.

kcullion commented 3 years ago

@rosibaj thanks! Ok, I think the 404 page was built too, in case @ciaranschutte wasn't involved with that

rosibaj commented 3 years ago

Tested April 15 in QA:

when im not logged in.... i cant see the file pages when i clock on them. I can see them in the file repository so i should be able to see the file pages publically.

ciaranschutte commented 3 years ago

File Repo is source of truth on this one. If you can see it in file repo you can see the page. There are still filtering bugs from arranger that have been referenced previously. https://github.com/icgc-argo/platform-api/issues/364 https://github.com/icgc-argo/platform-api/issues/393 As far as frontend is concerned, we deal with an empty data response correctly

ciaranschutte commented 3 years ago

edit: unrelated ~~ auth fixed on dev but login is garbling urls eg. https://platform-ui.dev.argo.cancercollaboratory.org/file/ffaa6aa2-a69f-56f4-bdfc-0a27d93fa98b%3FisOauth%3Dtrue# because we have the file portion and an auth portion.

wrapping into this fix https://github.com/icgc-argo/platform-ui/issues/1802 ~~

ciaranschutte commented 3 years ago

https://github.com/icgc-argo/roadmap/issues/779

icgc-argo / platform-ui

Permissions on Entity Pages: View + Download buttons #1875