feat: add permissions for public link shares

[benjaminfrueh]

Adds view, create, update and delete permissions for public table shares.

• UI changes are kept minimal for now, as the sharing sidebar should be updated to the unified sharing component in the future
• Rows created/edited via public link shares use public-<token> for the created_by and last_edit_byvalue.
• If a public link share has only create permission, the UI handles it as a public form with adjusted icon and text

Closes #2389

[enjeck]

i wonder if this breaks existing shares 🤔

[benjaminfrueh]

It should not break existing shares, anything going through PublicRowOCSController, so also the existing getRows() will have isPublicContext set to true. I just wanted to be more explicit and safe here, in what cases a empty userId should be allowed.

Was there any other case than CLI and isPublicContext when a empty userId should bypass the permission check? We can of course also revert this line and always return true here again, just to be sure.

I think we should think about a way to refactor this later and maybe use something else than an empty userId to bypass the permission checks.

[enjeck]

When a public share has delete permissions, the guest is able to delete rows from other tables 🙀 😱

To see, create a public share, open in an incognito/private tab and run in the console:

const TOKEN = location.pathname.match(/\/s\/([A-Za-z0-9]{16})\/?$/)?.[1] || 'TOKEN_HERE'
const ROW_ID = 16 // row from some other table

const res = await fetch(
  `${location.origin}/ocs/v2.php/apps/tables/api/2/public/${TOKEN}/rows/${ROW_ID}?format=json`,
  {
    method: 'DELETE',
    headers: {
      'OCS-APIRequest': 'true',
      ...(window.OC?.requestToken ? { requesttoken: OC.requestToken } : {}),
    },
  },
)

[benjaminfrueh]

Hi @enjeck and thank you for catching the delete issue, I updated the PR. For now to keep it consistent with the updateSet method, I passed the tableId to validate that the row belongs to the table.

[blizzz]

What we discussed earlier is good, with a non-blocking remark.

[blizzz]

theoretically both table and view can be null. Not from the calling Controller, given it is internally called after validation there is no much pressure… but it leaves a funny feeling in the tummy. #paranoia

[benjaminfrueh]

As a defensive fix, I now added a simple check to the create, update and delete in the PublicRowOCSController to be sure they can not call the service with both tableId and viewId being null.