-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize permission lookups for a user #10906
base: develop
Are you sure you want to change the base?
Optimize permission lookups for a user #10906
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some initial feedback. My eyes glazed over at the SQL but I'll request a review from @scolapasta for that part.
@@ -0,0 +1,9 @@ | |||
The following API have been added: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we've finalized the name of the API endpoint, please add it to the API Guide.
@@ -0,0 +1,9 @@ | |||
The following API have been added: | |||
|
|||
/api/users/{identifier}/allowedcollections/{permission} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can live with this name. I would probably camel case it as allowedCollections
.
How would we extend this API to datasets or files, if we needed to? Like below?
/api/users/{identifier}/allowedDatasets/{permission}
/api/users/{identifier}/allowedFiles/{permission}
Just playing around below, maybe instead we could have...
/api/users/{identifier}/permissions/collections/{permission}
/api/users/{identifier}/permissions/datasets/{permission}
/api/users/{identifier}/permissions/files/{permission}
? You might want to get some other opinions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the top APIs better. I think the allowedCollections etc. is more descriptive of what is being returned.
@qqmyers @scolapasta Any comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with either set of names.
doc/release-notes/6467-optimize-permission-lookups-for-a-user.md
Outdated
Show resolved
Hide resolved
Valid Permissions are: AddDataverse, AddDataset, ViewUnpublishedDataverse, ViewUnpublishedDataset, DownloadFile, EditDataverse, EditDataset, ManageDataversePermissions, | ||
ManageDatasetPermissions, ManageFilePermissions, PublishDataverse, PublishDataset, DeleteDataverse, DeleteDatasetDraft, and "any" as a wildcard option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine to list these here but it might be nice to have an API to list all these permissions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't have bother listing them in the release note but I wanted to point out the "any" permission for a wildcard. But since this wasn't asked for maybe we just leave it out of the release notes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, but do you think it's potentially useful to list these permissions via API? Maybe not for this PR but in the future.
The permissions should probably be listed in the guides for now. That way, the release note could link to them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An API would be nice. There is already a way to list the permissions in a role for the UI so adding a simple list of all permissions should be a quick add.
src/main/java/edu/harvard/iq/dataverse/PermissionServiceBean.java
Outdated
Show resolved
Hide resolved
|
||
/api/users/{identifier}/allowedcollections/{permission} | ||
|
||
This API lists the dataverses/collections that the user has access to via the permission passed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about cases where the user is granted access at runtime based on their membership in Shibboleth groups or IP groups?
We have this related comment in the code:
/**
* We don't expect this to support Shibboleth groups because even though
* a Shibboleth user can have an API token the transient
* shibIdentityProvider String on AuthenticatedUser is only set when a
* SAML assertion is made at runtime via the browser.
*/
On a related note, that comment is above the call to this method on ServiceDocumentManagerImpl
public List<Dataverse> getDataversesUserHasPermissionOn(AuthenticatedUser user, Permission permission)
Should this method be replaced by the new one in this PR:
public List<Dataverse> findPermittedCollections(AuthenticatedUser user, int permissionBit)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll swap it out and test it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pdurbin I added IP Group support but unfortunately ServiceDocumentManagerImpl doesn't have access to the request and therefore the ip address of the caller. Unless you know of a way to get it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see an obvious way. However, the SWORD API has never supported IP Groups and to my knowledge nobody has asked for it, so I think it's ok.
The main use case for IP Groups is read-only access, such as walking into a library and having access to data because you are on the library's IP range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a way to pass the IPAddress from the request made to Sword.
Co-authored-by: Philip Durbin <[email protected]>
This comment has been minimized.
This comment has been minimized.
src/main/java/edu/harvard/iq/dataverse/PermissionServiceBean.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…nagerImpl call for new call
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
src/main/java/edu/harvard/iq/dataverse/api/datadeposit/SWORDv2ServiceDocumentServlet.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, finally am managing to review - looks good overall, a few questions, easier to ask as a general comment imo:
- Does the sql query deal with nested groups (I think so, with the "With" but wanted to confrim?
- Does the last union (ip groups) need the exists / permissions bit clause?
- Do we have any sense on performace of this query yet?
@@ -0,0 +1,9 @@ | |||
The following API have been added: | |||
|
|||
/api/users/{identifier}/allowedcollections/{permission} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with either set of names.
|
This comment has been minimized.
This comment has been minimized.
OK on 1 and 3. For 2, maybe I'm still missing it - for the query part added in lines 143-152 for the ip groups, I don't see any reference to permisison bits). |
Ok. You are correct. there is no permission bits in IP groups. This is a bit confusing but here goes in regular groups: in IP Groups the role is the specific permission so there is no need to check the bit |
I don't think that's accurate (or at least now how it's designed. Sure, IP groups are mostly meant to allow read access (and usually file download), BUT it could be for the role "viewer". And technically, if you're logged in and from a certain ip address, then contributor role should work too. (as examples) |
I added the PERMISSIONBIT to the IpGroup sql and changed the test to test with "CURATOR" role |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
📦 Pushed preview images as
🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name. |
What this PR does / why we need it: The need to query "what dataverses does User x have Permission y on"
Which issue(s) this PR closes: #6467
Special notes for your reviewer: I'm not crazy about the api being called /allowedcollections/. Any suggestions for a better name would be appreciated.
Suggestions on how to test this: See IT test. Also test a group within a group for nested group permissions. I have tested it manually and it was working. For Shib testing I tested the sql manually. This still needs to be tested in a running environment.
Does this PR introduce a user interface change? If mockups are available, please link/include them here: No
Is there a release notes update needed for this change?: Included
Additional documentation: