Feature #6442
closed
[Workbench] [API] Support "world-readable, but not world-searchable" permission on projects: "anyone with the link can view"
Added by Tom Clegg over 9 years ago.
Updated 9 months ago.
Release relationship:
Auto
Description
This is similar to the "get a link to share" feature that's already available for collections, but the shareable link does not necessarily1 have an additional secret part: it could be just the project UUID.
It would have a toggle switch, presumably under the "Sharing" tab:
- Private - only people listed below can view
- Open - anyone with the link can view
(It may be less confusing to present the "Anonymous users" ("public") sharing option as a third choice here, rather than offering it as one of the selectable groups.)
One implementation challenge (compared to the collection case) is that either:
- the browser/session2 must remember the secret (whether or not it's just the shared project's UUID) -- and communicate it to Workbench when viewing an object inside the project, like a subproject or collection; or
- API server must automatically apply "secret is just UUID" permission -- but this requires opening the permission model such that any UUID of any object inside the shared project would effectively grant read access to the project, and this could cause unexpected sharing: if object X is moved from semi-secret project A to semi-secret project B, anyone who bookmarked X when it was in A would now also have permission to see B.
- Project changed from 35 to Arvados
- Subject changed from [Workbench] [API] Support "world-readable, but not indexed" permission on projects: "anyone with the link can view" to [Workbench] [API] Support "world-readable, but not world-searchable" permission on projects: "anyone with the link can view"
- Description updated (diff)
- Category set to Workbench
Two ways Workbench could remember the secret part of the project's secret link when browsing the project's contents
1. Copy those secrets into the Rails session (cookie) when they show up, and try each one in turn when the main session token gets a 404 in find_object_by_uuid (or always send all of them, and have API accept multiple tokens in a single request)
- If a user is logged in, the desired behavior is (presumably) to remember the secret in the user's account:
- Click secret link
- Log out
- Log in later from elsewhere
- Search for the secret-linked project and find it
- Presumably, this should be implemented in such a way that these saved permissions are also revoked when the project's "sharing state" switch gets flipped back to "private". This seems to require some new indirect permission handling on the API side, along the lines of "user X is allowed to use token Y".
- Should search results include objects that are accessible only because the user has opened a secret sharing link?
2. Keep the secret in the path, something like {workbench}/t/project-secret-goes-here/projects/{uuid}, {workbench}/t/project-secret-goes-here/collections/{uuid}
- This would permit:
- Person A views secret link to project X
- Click subproject/collection/whatever "thing-inside-X" inside the project
- Copy link of the "thing-inside-X" page, and send to person B
- Person B can now see the whole project X
- Getting Rails to keep context this way (without breaking anything else) might be crazy.
- Target version deleted (
Arvados Future Sprints)
- Target version set to Future
- Status changed from New to Closed
Also available in: Atom
PDF