Remove Link Password based on permission

[tbsbdr]

Description

User Stories 🗣️

• As a CISO I want that users "opt out" from setting a password for publicly shared links so that not setting a password for a link is a deliberate decision.

Value 💵

Empower security by default and make insecure links a conscious user decision

Userflow 💻

1. The User creates public link with "Viewer" permission
   

2. The user must enter a password (pw follows the policy)

4. Link is created successfully

5. The user can remove the password if he has the permission to opt out

5. The user can not remove the password if he has no permission to opt out

Acceptance Criteria

• New permission ReadOnlyPublicLinkPassword.Delete exists in the settings service
  • Assigned to "Admin"
  • Assigned to "Space Manager"
• Users with the opt-out permission can delete the password on read-only public links (OCS)

API Request as Einstein (has no opt out permission)

curl -L -X PUT 'https://localhost:9200/ocs/v2.php/apps/files_sharing/api/v1/shares/PjiUGbavRqtGNlO' \
-H 'Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ==' \
-F 'permissions="1"' \
-F 'name="Link"' \
-F 'password=""' \
-F 'expireDate=""'

Response 403 - Forbidden

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
    <meta>
        <status>error</status>
        <statuscode>104</statuscode>
        <message>user is not allowed to delete the password from the public link</message>
    </meta>
</ocs>

Definition of ready

[ ] everybody needs to understand the value written in the user story
[ ] acceptance criteria has to be defined
[ ] all dependencies of the user story need to be identified
[ ] feature should be seen from an end user perspective
[ ] user story has to be estimated
[ ] story points need to be less then 20

Definition of done

• Functional requirements
  [ ] functionality described in the user story works
  [ ] acceptance criteria are fulfilled
• Quality
  [ ] code review happened
  [ ] CI is green
  [ ] critical code received unit tests by the developer
  [ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
• Non-functional requirements
  [ ] no sonar cloud issues

[micbar]

@janackermann I am implementing the backend already. Needs tests. See linked ocis PR.

[AlexAndBear]

@micbar thx, please let me know as soon as those open prs are merged I will continue on that

[kulmann]

I'd like to propose that a user with the permission can opt out in the form field instead of setting a password in the first place and then deleting it afterwards. That would still be a conscious decision.. maybe ui wise even with "danger zone" checks like github does it in repo settings.

[micbar]

backend implementation is assuming that the "CREATE" always needs to enforce a password. Only the "UPDATE" can leave the password empty.

IMO this is the flow which was originally designed.

[micbar]

More arguments. If you implement it like this, we have no enforcement at all on the server side.

[micbar]

@janackermann PR in ocis is merged.

"Admin" and "SpaceAdmin" have the permission ReadOnlyPublicLinkPassword.Delete.
The PATCH allows an empty passwords parameter when this permission is set.

You need to set OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD=true to test this behavior.

[AlexAndBear]

Updated story points to 8, because lots of issues in web....