setting FRONTEND_ENABLE_RESHARING to false is not working for api #6651

KarunAtreya · 2023-06-28T06:13:27Z

Describe the bug

When the environment variable FRONTEND_ENABLE_RESHARING is set to false, resharing should not be possible but it can be done through api.

Steps to reproduce

Steps to reproduce the behavior:

setting env FRONTEND_ENABLE_RESHARING=false

Einstein creates a folder "test" and shares with Marie with permission 31 through api
Marie accepts the share requested by Einstein
Marie shares 'Shares/test" with Moss through api.
Moss can accept the share and "test" folder is visible

Expected behavior

When Einstein shares "test" folder with Marie with permission 31, the response should contain

 <permissions>15</permissions>

And Marie should get response as follows while resharing "/Shares/test" folder to Moss.

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
    <meta>
        <status>error</status>
        <statuscode>404</statuscode>
        <message>No share permission</message>
    </meta>
</ocs>

Actual behavior

When Einstein shares "test" folder with Marie with permission 31 using api
using curl command:

curl -k -XPOST "https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares" -u einstein:relativity -H "Content-Type: application/x-www-form-urlencoded" -d "shareType=0&shareWith=marie&path=test&permissions=31"

Response here

<ocs>
  <meta>
    <status>ok</status>
    <statuscode>200</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <id>286e1426-59af-49aa-afdf-903dabcba052:4c510ada-c86b-4815-8820-42cdf82c3d51:fb4a5d8a-23f1-4f97-ad76-8b4a8a3637ce</id>
    <share_type>0</share_type>
    <uid_owner>einstein</uid_owner>
    <displayname_owner>Albert Einstein</displayname_owner>
    <additional_info_owner>[email protected]</additional_info_owner>
    <permissions>31</permissions>
    <stime>1687930576</stime>
    <parent/>
    <expiration/>
    <token/>
    <uid_file_owner>einstein</uid_file_owner>
    <displayname_file_owner>Albert Einstein</displayname_file_owner>
    <additional_info_file_owner>[email protected]</additional_info_file_owner>
    <state>0</state>
    <path>/test</path>
    <item_type>folder</item_type>
    <mimetype>httpd/unix-directory</mimetype>
    <space_id>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51</space_id>
    <space_alias>personal/einstein</space_alias>
    <storage_id>shared::/Shares/test</storage_id>
    <storage>0</storage>
    <item_source>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!b1ffe3af-ef72-49ce-9c9b-635ea4ce6ddd</item_source>
    <file_source>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!b1ffe3af-ef72-49ce-9c9b-635ea4ce6ddd</file_source>
    <file_parent>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51</file_parent>
    <file_target>/Shares/test</file_target>
    <share_with>marie</share_with>
    <share_with_user_type>0</share_with_user_type>
    <share_with_displayname>Marie Skłodowska Curie</share_with_displayname>
    <share_with_additional_info>[email protected]</share_with_additional_info>
    <mail_send>0</mail_send>
    <name/>
  </data>
</ocs>
</p>

the response contains

<permissions>31</permissions>

Marie acceps the share requested by Einstein and
Again when Marie shares 'Shares/test" with Moss through api

using curl command:

curl -k -XPOST "https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares" -u marie:radioactivity -H "Content-Type: application/x-www-form-urlencoded" -d "shareType=0&shareWith=moss&path=/Shares/test&permissions=31"

Response here

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <id>286e1426-59af-49aa-afdf-903dabcba052:4c510ada-c86b-4815-8820-42cdf82c3d51:e2ec4cc8-69a3-467a-b951-94c9e2d16152</id>
    <share_type>0</share_type>
    <uid_owner>marie</uid_owner>
    <displayname_owner>Marie Skłodowska Curie</displayname_owner>
    <additional_info_owner>[email protected]</additional_info_owner>
    <permissions>31</permissions>
    <stime>1687932070</stime>
    <parent/>
    <expiration/>
    <token/>
    <uid_file_owner>einstein</uid_file_owner>
    <displayname_file_owner>Albert Einstein</displayname_file_owner>
    <additional_info_file_owner>[email protected]</additional_info_file_owner>
    <state>0</state>
    <path>/test</path>
    <item_type>folder</item_type>
    <mimetype>httpd/unix-directory</mimetype>
    <space_id>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51</space_id>
    <space_alias>personal/einstein</space_alias>
    <storage_id>shared::/Shares/test</storage_id>
    <storage>0</storage>
    <item_source>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!b1ffe3af-ef72-49ce-9c9b-635ea4ce6ddd</item_source>
    <file_source>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!b1ffe3af-ef72-49ce-9c9b-635ea4ce6ddd</file_source>
    <file_parent>286e1426-59af-49aa-afdf-903dabcba052$4c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51</file_parent>
    <file_target>/Shares/test</file_target>
    <share_with>moss</share_with>
    <share_with_user_type>0</share_with_user_type>
    <share_with_displayname>Maurice Moss</share_with_displayname>
    <share_with_additional_info>[email protected]</share_with_additional_info>
    <mail_send>0</mail_send>
    <name/>
  </data>
</ocs>

the response contains

  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
  </meta>

indicating reshare is possible

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

locally with env variables as follows

PROXY_ENABLE_BASIC_AUTH=true 
IDM_CREATE_DEMO_USERS=true 
OCIS_INSECURE=true 
FRONTEND_ENABLE_RESHARING=false

Additional context

This issue is same for files too.
While sharing, the share permission given should be discarded (ie: 16 should be subtracted) which is not happening

The text was updated successfully, but these errors were encountered:

saw-jan · 2023-06-28T07:11:55Z

I see this in the docs: https://doc.owncloud.com/ocis/next/deployment/services/s-list/frontend.html#environment-variables

Changing this value is NOT supported. Enables the support for resharing in the clients.

CC @ScharfViktor

micbar · 2023-06-28T07:34:23Z

@kobergj can we check that out?

kobergj · 2023-06-28T08:05:21Z

Imo this works as designed. FRONTEND_ENABLE_RESHARING only affects web requests. The server only checks two things:

(1) the sharer has CreateGrant permission
(2) The sharer cannot give more permissions than he has himself

When you create a share via API with permissions 31 the server cannot decide if this is a reshare or not. It only checks the above two points, which will both be true if you are e.g. manager of a space.

ScharfViktor · 2023-06-28T08:17:13Z

web sends 31 permission in sharing request and gets 15 in response. how does it work?
if we using api we have 31 in response

Screen.Recording.2023-06-28.at.10.12.08.mov

kobergj · 2023-06-28T08:25:18Z

web sends the role with the request. If role is set, permissions will be ignored by the server

ScharfViktor · 2023-06-28T08:37:38Z

It means that the backend is somehow processing this env
FRONTEND_ENABLE_RESHARING=false

curl -vk -XPOST "https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares" -u admin:admin -H "Content-Type: application/x-www-form-urlencoded" -d "shareType=0&shareWith=moss&path=/test&permissions=31&role=editor - 15 permission in response

without role:
curl -vk -XPOST "https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares" -u admin:admin -H "Content-Type: application/x-www-form-urlencoded" -d "shareType=0&shareWith=moss&path=/test&permissions=31 - 31 permission in response

kobergj · 2023-06-28T09:10:53Z

Correct. If role is set it will ignore permissions, so it doesn't matter what you put there. The roles will respect FRONTEND_ENABLE_RESHARING=false.

If you don't send role parameter it will use the given permissions. It will not check for FRONTEND_ENABLE_RESHARING=false in that case.

ScharfViktor · 2023-06-28T09:29:19Z

Okey, @kobergj thank you for clarification:

that means:

need to change this in docs: Changing this value is NOT supported. Enables the support for resharing in the clients.
@KarunAtreya your api test should use role instead of permissions. example step:

 When user "Brian" creates a share inside of space "share sub-item" with settings:
      | path      | test |
      | shareWith | Bob      |
      | role      | editor   |

KarunAtreya · 2023-06-28T09:52:58Z

okay then i will do as that

kobergj · 2023-06-28T11:28:02Z

@micbar is this the intended server behaviour? I mean just because it is the actual behaviour doesn't necessarily mean it is the correct one...

KarunAtreya · 2023-06-29T03:36:30Z

For now i will be writing tests using role only. But I also think server should be able to handle permissions only too because we get response in permission but not role. We also have tests on sharing using permissions only. If this is the intended behavior then we can solve the issue and add tests on permissions later.
Otherwise close this issue.

phil-davis · 2023-06-29T05:37:09Z

I wonder about the name FRONTEND_ENABLE_RESHARING and how the requirement would agree with the name.
Just looking at the name, I would guess that "frontend" refers to some client front-end (the web UI?). And that therefore the setting would be something that would be advertised by the server, and a client (like web UI) could respect that "requested resharing behavior". In that case there may not have to be any change to the server - the server would still allow the API requests, but cooperating clients would just not send requests to reshare.

Maybe "FRONTEND" refers to the OCS API? In that case if FRONTEND_ENABLE_RESHARING is off, then the OCS API endpoints would refuse requests that grant resharing permission or a role that allows resharing (or reduce the request by taking away "resharing") It seems strange to me if the server restricts granting reshare ability by roles, but still allows granting reshare ability by explicit permission requests. That would mean that a non-cooperative client can still decide to do reshare stuff by using explict permission values in requests. And that might surprise and admin who thought that they had disabled resharing.

Then there are the various GRPC CS3ORG... APIs - I suppose that a client that is talking to the server with GRPC... will not be affected by this env var setting.

(Sorry for the long text - I am just not sure what the requirement really is for this env var)

kobergj · 2023-06-29T07:15:40Z

Yes I agree. The behaviour of the server is not consistent. We need to clarify if ENABLE_RESHARING should be enforced by the server or if it is just a client side feature.
NOTE: Disabling resharing will not disable resharing for exisiting shares but only for newly created shares.

Regarding FRONTEND naming confusion: frontend is the name of one of the ocis services. It bundles appprovider, archiver, datagateway and ocs reva services into one service. In ocis all envvars either start with OCIS_ (if it is a var used in multiple services) or with the service name (if it is an envvar only for this service)

amrita-shrestha · 2024-04-09T04:55:57Z

Closing this issue beacuse reshare has been deprecated from ocis on this PR #8762. Mentioned in migration doc https://github.com/owncloud/docs-ocis/pull/739/files#diff-04cd79e526c8a7f0162d8fc5bc5fa8c501fe9e5899024268837c05a74349b26cR148-R149

KarunAtreya added the Type:Bug label Jun 28, 2023

KarunAtreya mentioned this issue Jun 28, 2023

ApiTest. next iteration #6606

Closed

51 tasks

amrita-shrestha closed this as completed Apr 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

setting FRONTEND_ENABLE_RESHARING to false is not working for api #6651

setting FRONTEND_ENABLE_RESHARING to false is not working for api #6651

KarunAtreya commented Jun 28, 2023 •

edited

Loading

saw-jan commented Jun 28, 2023 •

edited

Loading

micbar commented Jun 28, 2023

kobergj commented Jun 28, 2023 •

edited

Loading

ScharfViktor commented Jun 28, 2023 •

edited

Loading

kobergj commented Jun 28, 2023

ScharfViktor commented Jun 28, 2023

kobergj commented Jun 28, 2023 •

edited

Loading

ScharfViktor commented Jun 28, 2023

KarunAtreya commented Jun 28, 2023

kobergj commented Jun 28, 2023

KarunAtreya commented Jun 29, 2023

phil-davis commented Jun 29, 2023

kobergj commented Jun 29, 2023

amrita-shrestha commented Apr 9, 2024

setting FRONTEND_ENABLE_RESHARING to false is not working for api #6651

setting FRONTEND_ENABLE_RESHARING to false is not working for api #6651

Comments

KarunAtreya commented Jun 28, 2023 • edited Loading

Describe the bug

Steps to reproduce

Expected behavior

Actual behavior

Setup

Additional context

saw-jan commented Jun 28, 2023 • edited Loading

micbar commented Jun 28, 2023

kobergj commented Jun 28, 2023 • edited Loading

ScharfViktor commented Jun 28, 2023 • edited Loading

kobergj commented Jun 28, 2023

ScharfViktor commented Jun 28, 2023

kobergj commented Jun 28, 2023 • edited Loading

ScharfViktor commented Jun 28, 2023

KarunAtreya commented Jun 28, 2023

kobergj commented Jun 28, 2023

KarunAtreya commented Jun 29, 2023

phil-davis commented Jun 29, 2023

kobergj commented Jun 29, 2023

amrita-shrestha commented Apr 9, 2024

KarunAtreya commented Jun 28, 2023 •

edited

Loading

saw-jan commented Jun 28, 2023 •

edited

Loading

kobergj commented Jun 28, 2023 •

edited

Loading

ScharfViktor commented Jun 28, 2023 •

edited

Loading

kobergj commented Jun 28, 2023 •

edited

Loading