The public share mountpoint carries no space owner, so GET /drives/{pub}
came back without one and the drop page had no name to show. The request
runs as the share creator (publicshares auth), so the context user is who
shared the link; fill drive.Owner from it, id and display name, the same
source webdav fills oc:owner-display-name from. Deliberate disclosure to the
anonymous visitor, matching webdav and MS Graph's sharedDriveItem.owner.
A public link stat that fails for the password came back as a generic 401
"Access token is empty", so a client could not tell "show the password
field" from "the password was wrong". The proxy now marks the two cases
(it holds the auth result) and the graph service renders them as distinct
odata codes, publicLinkPasswordRequired and publicLinkPasswordInvalid, the
way webdav distinguishes ERR_MISSING_BASIC_AUTH from ERR_INVALID_CREDENTIALS.
The distinction rides in the body, never a WWW-Authenticate: Basic header,
which would pop the browser's native auth dialog instead of the app's
password field. The shared header/token contract lives in pkg/middleware.
Drives collection, the owner's personal drive, real drive id addressing, a
foreign link's drive and share type disclosure all answer 401 or omit the
data.
An editable link grants an upload session, a view only link answers 404. The
returned endpoint is not reachable from outside: CreateUploadSession hands
out the internal data server url, for authenticated callers just the same,
so the byte transfer stays with the graph upload work.
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.
Per review discussion: don't document accidental behavior. The contract is
simply "percent-encode each path segment, as MS Graph requires; encode ':'
as %3A" - OpenCloud allows ':' in names (OneDrive forbids it), so it's one
more character in the mandatory encode set, not a special case.
The parser is unchanged (split on ":/", decode once). This only rewrites the
docs (code comment, acceptance feature, PR description) to state the encode
contract, and drops the tests that relied on a raw, unencoded ':' in a file
name - keeping the "%3A" test that reflects the actual contract.
Review feedback: split the anchor/path and path/suffix on the structural
delimiter ":/" instead of a bare ":". Since the path and suffix always
start with "/", ":/" is the real delimiter, and a ":" *inside* a file or
directory name (which OpenCloud allows but MS Graph/OneDrive forbid) is
kept as part of the path instead of being mistaken for a separator.
A ":" sitting at a segment boundary (e.g. a name ending in ":") stays
ambiguous and must be percent-encoded as "%3A": the split works on the
literal ":/", so "%3A" is never a delimiter and decodes back to ":". This
is now documented in the code and the acceptance feature.
Tests: colon inside a name (with and without a suffix), the Stat path
carrying the colon, and the "%3A" boundary escape.
Cover the rewrite shapes the middleware handles end-to-end against a
real OpenCloud server: root-anchored, item-anchored, deep paths,
trailing colon, and the "/<path>:/<suffix>" sub-route form. Also
assert that NOT_FOUND and PERMISSION_DENIED both collapse to 404.
The /permissions sub-route is registered only at /v1beta1, and the
v1beta1 GetDriveItem handler is share-jail-only, so the v1beta1
mount of the middleware is exercised through the permissions
scenario, since there is no other v1beta1 endpoint that works for
regular personal-drive items.
Dominik Schmidt