-
Notifications
You must be signed in to change notification settings - Fork 2
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
As an Org Admin, I want to generate an Org API token that is scoped to a set of Unit(s) so that a user with this token can use the Org API with Unit scoping permissions taken into account #1059
Comments
Bas to refine this to determine which of the above listed org API endpoints are in scope. |
SRC is waiting for this. |
Logan to take a first pass then ping Bas for double check. |
A comment from the support team, data managers, of VU:
I think that the request can be translated into the following requirement:
|
|
@oharsta i am seeing second_factor_auth "YR4I62PUSPSFK2SJ7E6BDI5YE7XDZADS" i expect from the API spec that this should be a boolean value
endpoint GET colloboration details
|
EDIT: nevermind, I see this is more widespread than just the one endpoint, we can worry about it later. e.g. @oharsta the new PUT endpoint for updating collaboration units doesn't work well in swagger definition. When generating the curl command, it doesn't include the authorization token header. Example of what is currently generated:
Example of what is needed:
|
the syntax for the unit names is a little finnicky -- let's maybe help the user by at least having the example value include be multi-valued, this is how I needed to do that:
|
If I use the swagger authorization lock for the service, then press "Try it out", subsequently add an unit in the "Edit value" input area and press "Execute", then the following cURL is generated by flasgger:
|
yep all good, updated my comment |
seeing a fair amount of bugs. moving back to being tested. |
Pushed a generic fix for User |
gives correct 403 response when trying to delete a CO outside of my Unit ✅
gives incorrect 500 response when trying to delete a CO that I should be able to delete ❌
|
Sending an CO invitation with
|
The
If the
If the
In the schema in InvitationBulk.yaml this is correctly described:
I do agree that a 201 response is very misleading if no invitation is created. I'll add a validation to ensure that the |
re-checked ORG api endpoints collaboration with 5 scenarios
all looks to be working well, moving this to |
Use Cases:
POST /api/collaborations/v1
, Post a new collaboration and add units of API token to CODELETE /api/collaborations/v1/{co_identifier}
, Delete collaborationGET /api/collaborations/v1/{co_identifier}
, Get collaboration detailsPUT /api/collaborations/v1/{co_identifier}/members
| Update collaboration membershipDELETE /api/collaborations/v1/{co_identifier}/members/{user_uid}
| Delete collaboration membershipPUT /api/collaborations_services/v1/connect_collaboration_service
| Connect service to collaborationPUT /api/collaborations_services/v1/disconnect_collaboration_service
| Disconnect service from collaborationPOST /api/groups/v1
| Post a new groupDELETE /api/groups/v1/{group_identifier}
, Delete groupPOST /api/groups/v1/{group_identifier}
| Add group membershipPUT /api/groups/v1/{group_identifier}
| Update properties of a groupDELETE /api/groups/v1/{group_identifier}/members/{user_uid}
, Delete group membershipPUT /api/invitations/v1/collaboration_invites
| Put new collaboration invitationsGET /api/invitations/v1/invitations/{co_identifier}
| Get open invitations for a given collaborationDELETE /api/invitations/v1/{external_identifier}
, Delete invitation and check for the invitation{external_identifier}
-> CO -> API token has access to UnitGET /api/invitations/v1/{external_identifier}
, Get invitation details and check for the invitation{external_identifier}
-> CO -> API token has access to UnitGET /api/organisations/v1
| Get organisation including all collaborations, but filter out the collaborations where the API token does not have access to (e.g. is scoped to an unit which is not scoped to the collaborationThe solution for this last endpoint, is to return data associated with the units of the API token units only.
Logic for scoping a collaboration for an API token with unit(s)
Notes
The text was updated successfully, but these errors were encountered: