feat: Add @microsoft.graph.downloadUrl annotation and /content endpoi…#38
Open
feat: Add @microsoft.graph.downloadUrl annotation and /content endpoi…#38
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Libre Graph OpenAPI spec to support generating short-lived, pre-authenticated download URLs for driveItem content—mirroring Microsoft Graph’s @microsoft.graph.downloadUrl annotation and /content redirect pattern.
Changes:
- Adds optional
@microsoft.graph.downloadUrlinstance annotation to thedriveItemschema (opt-in via$select). - Introduces a new
driveItemSelect$selectparameter component to request the annotation. - Adds
GET /v1beta1/drives/{drive-id}/items/{item-id}/contentreturning302with aLocationheader, and wires$selectintoGetDriveItem.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The libre-graph-api spec currently provides no way to create signed links for a
driveItem. Clients that need file content and can't send auth headers for the download have to leave Graph and fall back to:PROPFINDwith theoc:downloadURLproperty, or/ocs/v1.php/cloud/user/signing-key, which is [planned for removal in opencloud](Deprecate and remove/cloud/user/signing-keyendpoint opencloud#1197)This forces every Graph-consuming client that ever needs to generate a signed url for a file to switch protocol to WebDAV.
Proposal
Mirror the Microsoft Graph API's two-pronged approach:
@microsoft.graph.downloadUrlinstance annotation ondriveItem, opt-in via$select, for clients that want to obtain the URL without following a redirect (useful for prefetching, scheduling, or inspecting the URL).GET /v1beta1/drives/{drive-id}/items/{item-id}/contentreturning302 Foundredirecting to the same pre-authenticated URL, for clients that just want to download and are happy to follow redirects.Both mechanisms return the same short-lived URL. The annotation is opt-in because computing the URL requires a signing operation; clients shouldn't pay that cost when they only wanted metadata.
We can use the regular dav endpoint as content for downloadUrl and as redirect target for /content.
What's in this PR
Three additions to
api/openapi-spec/v1.0.yaml:Schema: Adds
@microsoft.graph.downloadUrlas an optionalstringproperty on thedriveItemschema, alongside the existing@client.synchronizeand@UI.Hiddenannotations.Parameter component: Adds a new
driveItemSelectcomponent (following thedrivesSelect/permissionsSelectpattern) with anenumlisting@microsoft.graph.downloadUrl.Endpoints:
$selectto the existingGetDriveItemoperation.GetDriveItemContentoperation at/v1beta1/drives/{drive-id}/items/{item-id}/contentreturning302.Design decisions (happy to revisit)
Name:
@microsoft.graph.downloadUrl, matching MS Graph exactly. Alternative would be@libre.graph.downloadUrl, which would be more consistent with existing project-specific annotations like@libre.graph.hasTrashedItemsand@libre.graph.quickLink. I went with the MS-compatible name. Happy to switch to@libre.graph.downloadUrlif you take a different stance on this.Opt-in via
$select: Mirrors the WebDAVPROPFINDpattern, whereoc:downloadURLis only returned when explicitly requested. Signing is cheap but non-zero, and the resulting URL is short-lived garbage if unused.302 redirect on
/content: Matches MS Graph. We can just use the existing endpoint in WebDAV.Open questions for the implementation side (not in this PR)
These are for the corresponding opencloud implementation, but worth flagging here since they affect the contract:
TTL. WebDAV
PROPFIND'sdownloadURLhardcodes 30 minutes in Reva ([propfind.go:1770](https://github.com/opencloud-eu/reva/blob/main/internal/http/services/owncloud/ocdav/propfind/propfind.go#L1770)). MS Graph documents its equivalent as "a few minutes to 1 hour". The implementation should probably share a constant (or config) across both code paths for predictable behavior.Public shares. WebDAV's
downloadURLhas a separate signing path for public-share contexts (PublicShare.Signature).I'm willing to take care of the implementation.