Legacy OCM shares carry no WebDAV URI — every remote access hits the sender root (folders still show as files) #474
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up to #464. Dogfood: after v0.6.154, end + re-accept of the "Summer Slam" folder (and a second test folder) still shows Download instead of Browse.
Root cause (systematic-debugging pass, evidence from
internal/ocm/inbound.go+client.goon main):protocol.options.sharedSecretonly — noprotocol.webdavblock, no URI. Ourshareshandler fillsurionly on theProtocol.Webdav != nilbranch, so every NCShareInis stored withWebdavURI == "".IsRemoteDir/ListRemote/FetchRemotebuildscheme://server + WebdavURI— with the empty URI that is the Nextcloud homepage. The depth-0 PROPFIND answers non-207,IsRemoteDirreturns an error…derr == nil && isDirguard, no logging). So the v0.6.154 probe never had a chance, and there was zero evidence anywhere. Browse/Download against NC legacy shares are equally broken — they fetch HTML from the NC root.Spec answer (OCM IETF draft, Share Access steps 4–5): when the share carries no webdav URI, the receiver derives the endpoint from the sender's discovery document (
resourceTypes[].protocols.webdav—/public.php/webdav/on Nextcloud) and makes the PROPFIND tohttps://<sharedSecret>:@<sender-host><path>— i.e. Basic auth, shared secret as username (deprecated-but-kept legacy method). OurDiscovery.WebdavRootalready parses that field; it was just never used for share access.Fix (v0.6.156, TDD):
client.go: newremoteBase(ctx, sh)— explicit URI unchanged (Bearer); empty URI resolves the peer's cachedDisco.WebdavRoot, falling back to live discovery; newauthorize()sends Basic(secret, "") +X-Requested-Withfor legacy targets, Bearer otherwise. Wired into all three access paths, so existing stored rows heal without re-sharing.IsRemoteDir: dirness decided primarily by aresourcetypecollectionelement in the multistatus (servers that echo the request path verbatim break the trailing-slash heuristic); trailing slash stays as fallback.slog.Warn("ocm folder probe failed", …)— a silently swallowed best-effort probe hid this bug for a release.Lesson recorded: best-effort is fine, silent is not — every best-effort remote call needs a log line on failure (same lesson as the #454 refusal logging, one layer further out).
Shipped in v0.6.156, live on both dogfoods (
cairn_build_info{version="v0.6.156"}verified).PR #475, TDD with red witnessed on the runner (probe 404 against the server root + the collection-element case) before the implementation splices.
remoteBaseresolves the legacy endpoint from the peer's cached discovery (live-discovery fallback),authorizesends Basic with the secret as username for legacy targets,IsRemoteDirtrusts theresourcetypecollection element, and probe failures now land in the server log asocm folder probe failed.Because the fix sits in the client target resolution, existing stored shares heal in place — Browse/Download work without re-sharing. The folder flag, though, is only probed at accept, so the already-accepted "Summer Slam" needs one final end + re-accept to flip from Download to Browse. Any probe trouble will now be visible in the cairn-openbao pod log.