enh(Sharing): backend infrastructre for read-only link shares

[blizzz]

contributes to #67

• modifies oc_tables_share structure with two columns, token and password
• adds ShareOCSController with a route to create link shares
• adds a PageController front route to display the link share
• adds a ApiPublicColumnsController to retrieve columns for public
  links. It was not added to the existing ApiColumnsController, as it
  requires the userId of the logged-in user and I did not want to weaken
  this detail.
• adds an abstract controller for columns with shared functionality and
  make ApiColumnsController extend it.
• adds a PublicRowOCSController for retrieving rows through link shares
• adds a ShareToken value object
• adds a ShareControlMiddleware for share token and existance
  validation. It comes with the AssertShareToken attribute.
• extends Share entity with ShareToken and Password properties
• extends ShareMapper to find a share by the share token
• extends ShareService with a method to easily create link shares
• extends ResponseDefinitions with TablesPublicRow and
  TablesPublicColumn specs. Essentially tableIDs are not exposed and
  also user ids in lastEditBy and createdBy are not disclosed.
• extends RowService and ColumnService with methods to return such ^
  formatted result arrays.
• extends OpenAPI spec

Curl examples for added API endpoints

Create a share link without password

curl -u user:secret -X POST https://cloud.example.com/ocs/v2.php/apps/tables/api/2/tables/${TABLE_ID}/share -H "OCS-APIRequest: true"

fetch column information

curl -i https://cloud.example.com/ocs/v2.php/apps/tables/api/2/public/${SHARE_TOKEN}/columns -H "OCS-APIRequest: true"

fetch all rows

curl -i https://cloud.example.com/ocs/v2.php/apps/tables/api/2/public/${SHARE_TOKEN}/rows -H "OCS-APIRequest: true"

[blizzz]

@enjeck may keep this if new functionality goes into the main script, or otherwise we can change this if course and load a different one.

The share token is being provided via initialState a few lines below.

[enjeck]

Why do we unset the tableId but not the column/row ids? What makes tableId more riskier

[blizzz]

If we can prevent sending the row and column ids, we should do that. IIRC we need the column IDs as column meta data and rows are separate resourced and need to be linked together. Maybe we can hold back the row Id.

But if we allow to have deep/anchor links to the specific table or view row, we have to provide it i think.

The basic idea is to leak as little internal data as possible. Even if table IDs are known, without authentication and access you should not be able to do anything about them. As they are being sequential at the moment, having them withdrawn is not a big protection either.

That said, I am open to leave this item in place and send it along with the payload.

[enjeck]

we don't seem to have a way to get the title and description of the table/view given the token?

[blizzz]

we don't seem to have a way to get the title and description of the table/view given the token?

Indeed, those details… requires another public controller. No biggy. It would return either TablesView or TablesTable. They look similar, but can be kept apart by checking whether an tableId key is present. But since some information should be withdrawn, we need a new response definition anyways and can add a "nodeType" as well.

[enjeck]

Indeed, those details… requires another public controller.

We could use initialState too if that's easier?

[blizzz]

Indeed, those details… requires another public controller.

We could use initialState too if that's easier?

Indeed 👍 It does not change much for the response type definition, but would save that additional controller, that's right.

[blizzz]

@enjeck does this help? 0078f8d