The fallback reduced by hand, base name paths and a blank permission set,
a second copy of the reduction in degraded form. If the link of the request
cannot be resolved there is nothing to serve.
publicshare.ReduceResourceInfo/ReducePermissions replace both copies: the
publicstorageprovider's private filterPermissions plus its augment path
rewrite, and graph's reimplementation. Graph resolves the link of the request
(share root and grant, one GetPublicShare and one Stat) and applies the same
reduction the provider applies to its own responses. Paths below the public
drive are share-root relative now, on every route.
Vendored reva change, goes into the reva PR later.
The publicstorageprovider reduces child permissions to what the link grants,
field by field, but DenyGrant is not in the list: a child of a view-only link
could advertise deny. Same vendored-reva caveat as checkGraphDrivesPath, goes
into the reva PR later.
Navigating by id bypasses the publicstorageprovider, so the permission sets
are the owner's: a view-only link advertised delete and upload on items below
the root. Intersect with the link's permissions, the same reduction the
publicstorageprovider applies on its own responses; enforcement was always
intact through the token scope.
Items inside a public link keep their real ids, so the storage/space equality
check cannot hold below the public drive; the token scope guards access
instead. Paths in responses are cut to their base name there: they are
anchored at the owner's space root, and everything above the share root is
the owner's directory structure.
The scope handlers know CS3 request types and url paths; handing them the
*http.Request made every restricted scope fail with a type assertion error.
Pass the path, like reva's own http auth interceptor, and allow the graph
drives surface in the public share scope.
The vendored reva change (checkGraphDrivesPath) needs a reva PR before this
can go anywhere.
The legacy OC-Signature path already rejects methods outside
PRE_SIGNED_URL_ALLOWED_HTTP_METHODS, the JWT path did not. A leaked
signed download url could be used for PUT, DELETE, MOVE or PROPFIND
as the signing user for the lifetime of the signature.
$expand=thumbnails was only honored by sharedByMe and sharedWithMe. The
driveItem stat, the children listing and the root children listing now
honor it as well, so a client that lists a folder learns which items have
a preview instead of guessing from the mime type.
The thumbnails are set from the resource info the listing already has, so
a later preview check that needs more than the mime type has a single
place to sit. The two share listings carry driveItems only, they keep
matching on the mime type but share the url building.
Dominik Schmidt