Issue related to config OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD

[PrajwolAmatya]

Describe the bug

While running the API test with config OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD to true, and if we do not set password for upload, edit or contribute permissions, the returned response is 200.

It works fine manually.

Steps to reproduce

Steps to reproduce the behavior:

1. Set the config OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD to true.
2. Upload a file testfile.txt
3. Create a public link curl -k -X POST https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d'shareType=3&path=/testfile.txt&permissions=3' -uadmin:admin -v

Actual behavior

The response returns status code 200, and the link is created without password.
Actual Response:

> POST /ocs/v1.php/apps/files_sharing/api/v1/shares HTTP/1.1
> Host: localhost:9200
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 43
> Content-Type: application/x-www-form-urlencoded
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 1429
< Content-Type: text/xml; charset=utf-8
< Date: Tue, 30 May 2023 06:58:55 GMT
< Ocs-Api-Version: 1
< Vary: Origin
< 
<?xml version="1.0" encoding="UTF-8"?>
<ocs><meta><status>ok</status><statuscode>100</statuscode><message>OK</message></meta><data><id>oaTkAGKolCvrSud</id><share_type>3</share_type><uid_owner>admin</uid_owner><displayname_owner>Admin</displayname_owner><additional_info_owner>admin@example.org</additional_info_owner><permissions>1</permissions><stime>1685429935</stime><parent></parent><expiration></expiration><token>ScIBxsPOPnlySKw</token><uid_file_owner>admin</uid_file_owner><displayname_file_owner>Admin</displayname_file_owner><additional_info_file_owner>admin@example.org</additional_info_file_owner><state>0</state><path>/textfile.txt</path><item_type>file</item_type><mimetype>text/plain</mimetype><storage_id>shared::/textfile.txt</storage_id><storage>0</storage><item_source>e4e96167-5b8d-4c5f-93cd-e55a48f854ef$720baacf-e428-40a1-8df8-90ddf97a8b7f!c9f9bfa4-c22d-42a8-81a1-92c54731c2c2</item_source><file_source>e4e96167-5b8d-4c5f-93cd-e55a48f854ef$720baacf-e428-40a1-8df8-90ddf97a8b7f!c9f9bfa4-c22d-42a8-81a1-92* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host localhost left intact
c54731c2c2</file_source><file_parent>e4e96167-5b8d-4c5f-93cd-e55a48f854ef$720baacf-e428-40a1-8df8-90ddf97a8b7f!720baacf-e428-40a1-8df8-90ddf97a8b7f</file_parent><file_target>/textfile.txt</file_target><share_with_user_type>0</share_with_user_type><share_with_additional_info></share_with_additional_info><mail_send>0</mail_send><name></name><url>https://localhost:9200/s/ScIBxsPOPnlySKw</url></data></ocs>%

Now, if we update the public link using command:
curl -k -X PUT https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares/<share_id> -d'permissions=3' -uadmin:admin -v

Then it returns the response:

> PUT /ocs/v1.php/apps/files_sharing/api/v1/shares/oaTkAGKolCvrSud HTTP/1.1
> Host: localhost:9200
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 12
> Content-Type: application/x-www-form-urlencoded
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 163
< Content-Type: text/xml; charset=utf-8
< Date: Tue, 30 May 2023 07:01:10 GMT
< Ocs-Api-Version: 1
< Vary: Origin
< 
<?xml version="1.0" encoding="UTF-8"?>
* Connection #0 to host localhost left intact
<ocs><meta><status>error</status><statuscode>400</statuscode><message>No updates specified in request</message></meta></ocs>

Is this the actual behavior?

[PrajwolAmatya]

It works when we fisrt set the permission to read and then update the link to edit permission, then the enforce-password config works fine. Is it supposed to have that behavior?

[micbar]

It works when we fisrt set the permission to read and then update the link to edit permission, then the enforce-password config works fine. Is it supposed to have that behavior?

This is the User Flow in the WebUI

The api should also enforce passwords when creating a public share. @kobergj

[dragonchaser]

see cs3org/reva#3970