OCM. Restrict sharing roles to Editor / Viewer in sharing dialog

[butonic]

things I noticed when trying to create a user share

• users with the same name cannot be distinguished ... api returns an identities property for federated users -> tracked in OCM. Admin Settings > Users: indicate which account is a federated account ++ remove actions from users. #9747
• creating a share sends a json body with a Content-Type: application/x-www-form-urlencoded header. Why not application/json? then the firefox devtools would know how to parse the body and allow navigating it properly...
• the weight in all roleDefinitions at https://cloud.ocis.test/graph/v1beta1/roleManagement/permissions/roleDefinitions is 0 ... shouldn't that represent the order...
  • ok, the order is determined by the weight in the GET /drives/{driveid}/items/{itemid}/permissions response. there all rolas have a different weight.
  • omit the weight completely in the /roleManagement/permissions/roleDefinitions endpoint
• how will the web iu or any other client know which roles can be applied to a share?
  • when selectin a driveItem / resource, web makes a GET /drives/{driveid}/items/{itemid}/permissions request that returns all allowd actions and roles.
  • the request does not carry any user information. the web ui matches the returned list of roles with the more extensive list from the /roleManagement/permissions/roleDefinitions endpoint
  • we can add two new roles (view and edit) for federated users, but it will require a new condition
    • we can add the conditions to existing roles and filter them base on those conditions
  • the condition property is described in ms grap
    • the beta api has $ResourceIsSelf and $SubjectIsOwner
    • the v1 API has @Subject.objectId == @Resource.objectId and @Subject.objectId Any_of @Resource.owners
  • we have exists @Resource.Folder, exists @Resource.File and exists @Resource.Root
  • none of these are sufficient to distinguish federated from normal users
  • what is the syntax used in the condition property, anyway?
    • it does not seem to be a filter operator: https://learn.microsoft.com/en-us/graph/filter-query-parameter?tabs=http#operators-and-functions-supported-in-filter-expressions
    • we could use filter expressions. exists @Resource.Folder could be has @Resource.Folder.
    • how does web evaluate the condition?
    • it seems to follow the SDDL conditional expressions

[micbar]

@butonic the condition syntax is not for the clients. The server filters that based on the resource

[butonic]

@micbar it cannot do that because the user first selects the resource and then searches for a recipient. web has to match the known roles with the available sharing roles AND the type of recipient. On the server side we currently do not have the share recipient available.

[butonic]

also note that when creating a federated share we store a grantee without the protocol in the idp. then when listing the shares the json repository tries to compare an idp with protocol, so users are never treated equal in:

diff --git a/pkg/ocm/share/repository/json/json.go b/pkg/ocm/share/repository/json/json.go
index 139a320b4..5d21695b2 100644
--- a/pkg/ocm/share/repository/json/json.go
+++ b/pkg/ocm/share/repository/json/json.go
@@ -396,6 +396,10 @@ func (m *mgr) ListShares(ctx context.Context, user *userpb.User, filters []*ocm.
        }
 
        for _, share := range m.model.Shares {
+               // FIXME utils.UserEqual(user.Id, share.GetGrantee().GetUserId()) is false because the
+               // user.id.idp is "https://cloud.ocis.test"
+               // and the share.GetGrantee().GetUserId().idp is just "cloud.ocis.test"
+               // the protocol was deliberately removed from the idp in https://github.com/cs3org/reva/pull/1009
                if utils.UserEqual(user.Id, share.Owner) || utils.UserEqual(user.Id, share.Creator) || utils.UserEqual(user.Id, share.GetGrantee().GetUserId()) {
                        // no filter we return earlier
                        if len(filters) == 0 {

the protocol in the ocmprovider.json was deliberately removed in cs3org/reva#1009

a quickfix to create grantees with the protocol would be to use the user idp as is when creating shares

diff --git a/services/graph/pkg/service/v0/api_driveitem_permissions.go b/services/graph/pkg/service/v0/api_driveitem_permissions.go
index 4c169b1d28..3b5299fa09 100644
--- a/services/graph/pkg/service/v0/api_driveitem_permissions.go
+++ b/services/graph/pkg/service/v0/api_driveitem_permissions.go
@@ -281,7 +281,7 @@ func createShareRequestToFederatedUser(user libregraph.User, resourceId *storage
                        Id: &storageprovider.Grantee_UserId{UserId: &userpb.UserId{
                                Type:     userpb.UserType_USER_TYPE_FEDERATED,
                                OpaqueId: user.GetId(),
-                               Idp:      providerInfo.Domain, // the domain is persisted in the grant as u:{opaqueid}:{domain}
+                               Idp:      *user.GetIdentities()[0].Issuer, // the domain is persisted in the grant as u:{opaqueid}:{domain}
                        }},
                },
                RecipientMeshProvider: providerInfo,

[butonic]

We could use $filter on the @libre.graph.permissions.roles.allowedValues directly:

GET /drives/{driveid}/items/{itemid}/permissions?$filter=@libre.graph.permissions.roles.allowedValues/rolePermissions/any(p:contains(p/condition, '@Subject.UserType=="Federated"')) (see https://learn.microsoft.com/en-us/graph/aad-advanced-queries?tabs=http for more syntax examples).

Granted, the formulated condition check is not perfect. it does not fully parse the SDDL, but we don't need to. I just want to have an Odata spec conforming request that expresses that the client only wants to have actions for federated users. Think of it as a fancy way of saying GET /drives/{driveid}/items/{itemid}/permissions?actionFilter='userType==Federated'

The client has to use a different url to get the ist of federated users. This is the only thing I can come up with that fits our libregraph spec.