Sharing with a via SCIM create group doesn't work

[T0mWz]

Created a group with only local users on same environment;

Create a share;

{"reqId":"ZIHD7XTqQg8xLkRoogEv8AAAABA","level":3,"time":"08\/Jun\/2023:14:05:02","remoteAddr":"10.234.2.58","user":"surfsara","app":"no app in context","method":"POST","url":"\/ocs\/v2.php\/apps\/files_sharing\/api\/v1\/shares?format=json","message":"Failed to notify remote server of mixed group share, panic (Sharing testmap failed, could not find TestGroup (uniharderwijk_surfdrive_test) (SRAM CO), maybe the server is currently unreachable.)"}

Delete the share

{"reqId":"ZIHDg11QfCRhkVbqfOOH1wAAAAQ","level":3,"time":"08\/Jun\/2023:14:03:17","remoteAddr":"10.234.2.58","user":"surfsara","app":"no app in context","method":"DELETE","url":"\/ocs\/v2.php\/apps\/files_sharing\/api\/v1\/shares\/2325?format=json","message":"Failed to notify remote server of mixed group share, panic (Unsharing testmap failed, could not find TestGroup (uniharderwijk_surfdrive_test) (SRAM CO), maybe the server is currently unreachable.)"}

[soltanireza65]

@T0mWz what do you mean by Share with SCIM?

[michielbdejong]

I think the steps to reproduce would be:

1. create a group through SCIM
2. share a file or folder with that group
3. delete that share

[T0mWz]

I think the steps to reproduce would be:

1. create a group through SCIM
2. share a file or folder with that group
3. delete that share

Correct!

Can you not better add the usernames here as the really are, so with an @. And set a # for the remote host? Then the normal OC share still keep working, then you only have to add the knowledge for federated group shares and is this table just fine.

MariaDB [miskatonic_tst_oc]> select * from oc_group_user where uid like '%#%';
+---------------------------------------------------------+------------------+
| gid                                                     | uid              |
+---------------------------------------------------------+------------------+
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | breek001#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | es000003#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | reint001#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | zoete001#surf.nl |
| TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)      | wezep001#surf.nl |
| TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)      | zoete001#surf.nl |
+---------------------------------------------------------+------------------+

[soltanireza65]

I have just created a group in oc1.docker with:

{
  "members": [
    {
      "value": "zoete001@oc2.docker"
    }
  ],
  "id": "testgroup (uniharderwijk_democollab) (SRAM CO)"
}

and try to share a file with the same group,

and also can unshare the shared file successfully maybe @T0mWz has not installed the fedeatedGroups app in tst-aperture.data.surfsara.nl

[michielbdejong]

@T0mWz tst-aperture.data.surfsara.nl is the receiving server, right? Can you confirm whether at least the opencloudmesh app is installed there?

[T0mWz]

@michielbdejong @soltanireza65
Yes, opencloudmesh 0.1.0 and federatedgroups are installed there too.

[T0mWz]

But what are your usernames? @michielbdejong @soltanireza65 See also https://github.com/SURFnet/rd-sram-integration/issues/159

Basically all our usernames have an @-sign by default... I'm affraid you have not usernames with an @ sign..?

The choice for an @-sign for an OCM lookup is a bit unfortunate. Design flaw 😅

[michielbdejong]

@navid-shokri can you confirm that when you're testing this in dev-stock, you are using usernames that include @-signs? Also, it seems from https://github.com/SURFnet/rd-sram-integration/issues/184#issuecomment-1582611787 that Tom's group is in the wrong db table, right?

[T0mWz]

However these users (wezep001@surf.nl and zoete001@surf.nl) are both on the same OC instances (tst-miskatonic by the way), so these are just local users where a SCIM group is created for. OCM is not yet involved here. So what I try to say here;

I think the steps to reproduce would be:

1. create a group through SCIM
2. share a file or folder with that group
3. delete that share

Correct!

Can you not better add the usernames here as the really are, so with an @. And set a # for the remote host? Then the normal OC share still keep working, then you only have to add the knowledge for federated group shares and is this table just fine.

MariaDB [miskatonic_tst_oc]> select * from oc_group_user where uid like '%#%';
+---------------------------------------------------------+------------------+
| gid                                                     | uid              |
+---------------------------------------------------------+------------------+
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | breek001#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | es000003#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | reint001#surf.nl |
| Demo collaboration (uniharderwijk_democollab) (SRAM CO) | zoete001#surf.nl |
| TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)      | wezep001#surf.nl |
| TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)      | zoete001#surf.nl |
+---------------------------------------------------------+------------------+

I should not replace the @ with an # where these users are just local and then normal group share can handle that well too.

MariaDB [miskatonic_tst_oc]> select * from oc_accounts where user_id like 'wezep%';
+------+-------+------------------+------------------+------------------+-------+------------+------------------+-----------------------------------------+-------+---------------+
| id   | email | user_id          | lower_user_id    | display_name     | quota | last_login | backend          | home                                    | state | creation_time |
+------+-------+------------------+------------------+------------------+-------+------------+------------------+-----------------------------------------+-------+---------------+
| 1050 | NULL  | wezep001@surf.nl | wezep001@surf.nl | wezep001@surf.nl | NULL  |          0 | OC\User\Database | /var/www/owncloud/data/wezep001@surf.nl |     1 |    1683889007 |
+------+-------+------------------+------------------+------------------+-------+------------+------------------+-----------------------------------------+-------+---------------+
1 row in set (0.001 sec)

[navid-shokri]

why are your users stored in oc_group_user? according to our new version, all of them should be stored in oc_fg_group_user. :thinking: @T0mWz

[T0mWz]

Uh, I don't do that.. I just create a group via SCIM/ your federatedgroups. 😉

[navid-shokri]

So I send this request to my SCIM controller:

curl --request POST \
  --url http://localhost:42319/index.php/apps/federatedgroups/scim/Groups \
  --header 'Content-Type: application/json' \
  --header 'x-auth: Bearer VGfRewYoHu6lTCoVSAQ6GevfGYznIBZT' \
  --cookie 'ocvzvyc9ti1g=3ke8v4tvguika5b618elqodovu; ocp9eud6ezkt=u2b56ls1bpt8d57vcloe1c6q0m; oci50bcnk8nq=gjjhcavr17mcff3vadvjdn47uk; ocxougkoe4sh=hu5ve2k0i03jvoobct7h7gapfk' \
  --data '{
  "members": [
    {
      "value": "navid@pondersource.com@oc2.docker"
    },
        {
      "value": "Tom@surfnet.nl@oc2.docker"
    }
  ],
  "id": "IssueNo184"
}'

And it is my tables :

MariaDB [efss]> select * from oc_fg_groups;
+------------+
| gid        |
+------------+
| IssueNo184 |
+------------+
1 row in set (0.000 sec)

MariaDB [efss]> select * from oc_fg_group_user;
+------------+-----------------------------------+
| gid        | uid                               |
+------------+-----------------------------------+
| IssueNo184 | navid@pondersource.com#oc2.docker |
| IssueNo184 | Tom@surfnet.nl#oc2.docker         |
+------------+-----------------------------------+
2 rows in set (0.000 sec)

So It seems there is a problem with Tom's version. @michielbdejong

[navid-shokri]

:boom: @T0mWz are you sure you have the same group name on receiving party? I shared a file with the IssueNo184 group in my testing environment despite there being no same group name and guess what?

Sharing images.jpg failed, could not find IssueNo184, maybe the server is currently unreachable.

[T0mWz]

So I send this request to my SCIM controller:

curl --request POST \
  --url http://localhost:42319/index.php/apps/federatedgroups/scim/Groups \
  --header 'Content-Type: application/json' \
  --header 'x-auth: Bearer VGfRewYoHu6lTCoVSAQ6GevfGYznIBZT' \
  --cookie 'ocvzvyc9ti1g=3ke8v4tvguika5b618elqodovu; ocp9eud6ezkt=u2b56ls1bpt8d57vcloe1c6q0m; oci50bcnk8nq=gjjhcavr17mcff3vadvjdn47uk; ocxougkoe4sh=hu5ve2k0i03jvoobct7h7gapfk' \
  --data '{
  "members": [
    {
      "value": "navid@pondersource.com@oc2.docker"
    },
      {
      "value": "Tom@surfnet.nl@oc2.docker"
    }
  ],
  "id": "IssueNo184"
}'

And it is my tables :

MariaDB [efss]> select * from oc_fg_groups;
+------------+
| gid        |
+------------+
| IssueNo184 |
+------------+
1 row in set (0.000 sec)

MariaDB [efss]> select * from oc_fg_group_user;
+------------+-----------------------------------+
| gid        | uid                               |
+------------+-----------------------------------+
| IssueNo184 | navid@pondersource.com#oc2.docker |
| IssueNo184 | Tom@surfnet.nl#oc2.docker         |
+------------+-----------------------------------+
2 rows in set (0.000 sec)

So It seems there is a problem with Tom's version. @michielbdejong

Will update my app, it's version of yesterday. Don't know if something is changed what can be related..

[T0mWz]

@navid-shokri @soltanireza65 ; Updated the app, so we have a new error.

2023-06-09 08:57:38,793 INFO Handle SCIM group call for: TestGroup (uniharderwijk_surfdrive_test) (SRAM CO) on environment miskatonic
2023-06-09 08:57:38,827 INFO JSON PAYLOAD:{"displayName": "TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)", "externalId": "3f938b6b-cbe0-4856-beb3-91dffa773c15@sram.surf.nl", "members": [{"display": "", "value": "zoete001@surf.nl"}, {"display": "", "value": "wezep001@surf.nl"}, {"display": "", "value": "zoete001@surf.nl"}, {"display": "", "value": "wezep001@surf.nl"}], "urn:mace:surf.nl:sram:scim:extension:Group": {"description": "Provisioned by service Research Drive test - ", "labels": [], "urn": "uniharderwijk:surfdrive_test:srd_test-testgroup"}, "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group", "urn:mace:surf.nl:sram:scim:extension:Group"], "id": "TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)", "meta": {"created": "2023-05-09T09:28:12.589456", "lastModified": "2023-05-09T09:28:12.602001", "location": "/Groups/848a0f5d-b492-4580-80f1-1950cf7be410", "resourceType": "Group"}}
2023-06-09 08:57:38,828 INFO Would make the following call to HTTP endpoint:
url : https://tst-miskatonic.data.surfsara.nl/index.php/apps/federatedgroups/scim/Groups
 headers:{'Content-Type': 'application/json', 'x-auth': 'Bearer 7d68a22d-8a98-4096-889b-351f2f2e9182'}
 method: POST
 payload:{"displayName": "TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)", "externalId": "3f938b6b-cbe0-4856-beb3-91dffa773c15@sram.surf.nl", "members": [{"display": "", "value": "zoete001@surf.nl"}, {"display": "", "value": "wezep001@surf.nl"}, {"display": "", "value": "zoete001@surf.nl"}, {"display": "", "value": "wezep001@surf.nl"}], "urn:mace:surf.nl:sram:scim:extension:Group": {"description": "Provisioned by service Research Drive test - ", "labels": [], "urn": "uniharderwijk:surfdrive_test:srd_test-testgroup"}, "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group", "urn:mace:surf.nl:sram:scim:extension:Group"], "id": "TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)", "meta": {"created": "2023-05-09T09:28:12.589456", "lastModified": "2023-05-09T09:28:12.602001", "location": "/Groups/848a0f5d-b492-4580-80f1-1950cf7be410", "resourceType": "Group"}}
 json:
2023-06-09 08:57:39,397 ERROR Did not get success response from API! - HTTPcode: 400 - {"status":"error","message":"cannot find the given group TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)","data":null}
2023-06-09 08:57:39,398 ERROR Failed to make request to HTTP endpoint. Error: Did not get success response from API - HTTPcode: 400 - {"status":"error","message":"cannot find the given group TestGroup (uniharderwijk_surfdrive_test) (SRAM CO)","data":null}

Hmm. The group is created;

MariaDB [miskatonic_tst_oc]> select * from oc_fg_groups;
+----------------------------------------------------+
| gid                                                |
+----------------------------------------------------+
| TestGroup (uniharderwijk_surfdrive_test) (SRAM CO) |
+----------------------------------------------------+
1 row in set (0.003 sec)

Users are not there;

MariaDB [miskatonic_tst_oc]> select * from oc_fg_group_user;
Empty set (0.003 sec)

This time group is not longer in oc_groups;

MariaDB [miskatonic_tst_oc]> select * from oc_groups where gid like 'TestGroup%';
Empty set (0.003 sec)

MariaDB [miskatonic_tst_oc]> select * from oc_group_user where gid like 'TestGroup%';
Empty set (0.001 sec)

Also not able to lookup the group;

[navid-shokri]

but I ran the same request and it worked :exploding_head:

https://github.com/SURFnet/rd-sram-integration/issues/184#issuecomment-1584188270

did you delete the group with the same name that was inserted into oc_group?

[michielbdejong]

I was able to reproduce it \o/

@navid-shokri shall we do a screensharing now to go fix it?

[michielbdejong]

Ah bummer it was because of https://github.com/pondersource/dev-stock/commit/97e9728b82c467f230d4d22d8ee46a07b27d235e Back to testing.

[michielbdejong]

It seems the original issue was fixed by updating the app but now there are two new problems. Splitting those out: #190 and #191.