[stable29] fix(share_api): Respect requested permissions or error out #49606
Conversation
nfebe
requested review from
provokateurin,
come-nc,
CarlSchwan and
artonge
and removed request for
provokateurin and
come-nc
nfebe
force-pushed
the
fix/no-issue/show-file-drop-permissions-correctly
branch
2 times, most recently
from
c401885 to
a0b10ae
Compare
|
Tests related to I am not sure if that parameter is useful in the context of the new sharing UI. CC: @artonge |
| if ($this->shareManager->outgoingServer2ServerSharesAllowed()) { | ||
| $permissions |= Constants::PERMISSION_SHARE; | ||
| } |
The share API currently always adds read permissions sent in share request with the argument that all shares must have read permissions. That this not true as link and email shares allowed not to. In addition to the above, there is a check that ensures any share which is not a link or email share must have read permissions. There is also protection for legacy integrations where if no permissions are sent at all default permissions are set. So it does not make sense to make any sort of additions to the permissions that a client has sent, as the response would be different from what the client expects. Signed-off-by: nfebe <[email protected]>
nfebe
force-pushed
the
fix/no-issue/show-file-drop-permissions-correctly
branch
from
a0b10ae to
5ed3db9
Compare
skjnldsv
changed the title
|
Why is this PR against stable 29 ? |
This is related to a bug that more visible on 29 with "File drop" when the client sends File requests on 30, sends 4 but the client would handle 20 as still a file request. That works, it continues to build on incorrect complexity? |
The share API currently always adds read permissions sent in share request with the argument that all shares must have read permissions. That this not true as link and email shares allowed not to.
In addition to the above, there is a check that ensures any share which is not a link or email share must have read permissions. There is also protection for legacy integrations where if no permissions are sent at all default permissions are set.
So it does not make sense to make any sort of additions to the permissions that a client has sent, as the response would be different from what the client expects.