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.

resolved since

[blizzz]

cypress: it is always the last three cases that fail. So far.

[benjaminfrueh]

cypress: it is always the last three cases that fail. So far.

@blizzz The toast message "Row successfully created." was stacking up ~5 times and covering elements required for cypress tests. The test opens the create row modal, fills and sends it in fast succession. I now added to the cypress helper that any success toast from creating a row will be closed before continue.

Cypress should pass again with that change now.

Before this PR, the success toast was only shown when the "Add more" option is active in the create modal. I changed this with the newly introduced form mode (create only permission), to always give feedback even if no added row is visually shown without the read permission.

[blizzz]

/backport to stable1.0

nope, link sharing was introduced in 2.0 only