Core: Unexpected error creating public link in absence of "publicUpload" parameter

[jesmrec]

Steps to reproduce

1. In sharing dashboard of admin web UI, disable Allow public uploads
2. Client requests a new public link to a folder. (if the Allow public uploads capability is disabled in admin UI dashboard, in clients it is not displayed). The option is not included in the request, so it is optional:

Expected behaviour

New public link is created.

Current behaviour

Server returns an error:

Server configuration

Version 10.0.1RC1
This behaviour does not happen in 10.0.0

This curl command can be useful:

curl -k \
    -H 'Host:xxxxxx' \
    -H 'Content-Type:application/x-www-form-urlencoded' \
    -H 'Accept:*/*' \
    -H 'User-Agent:Mozilla/5.0 (iOS) ownCloud-iOS/3.5.3' \
     [...]
    -H 'Authorization:Basic YWRtaW46UGFzc3dvcmQ=' \
    -H 'OCS-APIREQUEST:true' \
    -X POST 'https://xxxxxxxxxxx/ocs/v1.php/apps/files_sharing/api/v1/shares' \
    --data-binary 'path=/Photos/&shareType=3&name=Photoslink'

[SamuAlfageme]

I can reproduce in the Desktop client. Can be fixed appending permissions=1 in the share request, in the same fashion the webUI does:

-X POST 'https://<server_url>/ocs/v1.php/apps/files_sharing/api/v1/shares' \ 
--data-binary 'path=/Photos&shareType=3&name=Photoslink&permissions=1'

But, of course, permission-handling should be transparent to clients.

[davivel]

I can reproduce in the Desktop client. Can be fixed appending permissions=1 in the share request.

That's not a proper solution, IMHO.

Both permissions and publicUploads are optional parameters. A POST request not including them should default to a new resource with valid values for them, not to a version that is forbidden by the current server configuration.

cc @PVince81 @felixheidecke

[PVince81]

Ok that's a bug. I fixed an issue recently there and remember the code is supposed to default to 1 if no "permissions" is set. I'll have a look...

[PVince81]

Wrote two integration tests, could not reproduce the issue... permissions default to 1 on master.

Will try with curl...

[PVince81]

on master:

% curl -u admin:admin -H 'Content-Type:application/x-www-form-urlencoded' -H 'OCS-APIREQUEST:true' -X POST 'http://localhost/owncloud/ocs/v1.php/apps/files_sharing/api/v1/shares' --data-binary 'path=/welcome.txt&shareType=3&name=Photoslink'

I get a proper XML response.

Now let's check 10.0.1RC1...

[PVince81]

ah, oh course... it needs to be a folder, not a file... retrying...

[nasli]

If you give more than 1 for permissions on create is not allowed (well ignored), we need the publicUpload to give more permissions

[PVince81]

It needs to work the same like it did in 9.1

[PVince81]

ok, then maybe it's the files_drop bit that changed behavior slightly...

[PVince81]

this commit: b621ea2d2d9e2d7470e8d5fc7bcd22ef08276bb5

I'll try and fix this...

[PVince81]

seems it was a wrongly written condition, PR here https://github.com/owncloud/core/pull/27927 please review

[jesmrec]

Reviewed:

• [X] iOS
• [X] Android

any check related with desktop client @SamuAlfageme?

@PVince81

[SamuAlfageme]

LGTM 👍

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.