You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having a public link with role "Upload" still lists the content via PROPFIND.
Steps to reproduce
Steps to reproduce the behavior:
Create a folder with some files
Create a public link with "Upload" role
Do a propfind, e.g. with curl: curl --insecure -X PROPFIND -H "Depth: 1" -H "Content-Type: text/xml" 'https://host.docker.internal:9200/remote.php/dav/public-files/dEbwwApymmGZhSd' | xmllint --format - (set your public link token in the URL according to your public link)
Expected behavior
Some 404 or whatever. But folder listing must be prevented.
Actual behavior
PROPFIND lists all files and folders as if the link had read or higher permissions.
Setup
oCIS single binary on commit hash ca66a9f7516734e7a3c64074d37f266dd90f702f.
The text was updated successfully, but these errors were encountered:
Ahh, I wondered why it worked correctly for the web. for "upload permissions" PROPFIND request use depth=0. In this way we block the content for public.
Describe the bug
Having a public link with role "Upload" still lists the content via PROPFIND.
Steps to reproduce
Steps to reproduce the behavior:
curl --insecure -X PROPFIND -H "Depth: 1" -H "Content-Type: text/xml" 'https://host.docker.internal:9200/remote.php/dav/public-files/dEbwwApymmGZhSd' | xmllint --format -
(set your public link token in the URL according to your public link)Expected behavior
Some 404 or whatever. But folder listing must be prevented.
Actual behavior
PROPFIND lists all files and folders as if the link had
read
or higher permissions.Setup
oCIS single binary on commit hash
ca66a9f7516734e7a3c64074d37f266dd90f702f
.The text was updated successfully, but these errors were encountered: