fix(api): let an artist download their own track with downloads off - #1033
Merged
Conversation
The download endpoint only ever serves `track.Download`, which dbv1 populates solely for tracks the public may download (`is_downloadable`). About four in five tracks on the network have that off, and for those the artist's own "Download File" button on the edit page - the one paired with "Replace File", which exists precisely so an artist can retrieve what they uploaded - got a 404 and surfaced it as "Something went wrong. Please check your connection and storage and try again." Fall back to signing a link for a requester who proves, with the wallet signature already on the request, that they own the track or manage the account that does. Access for everyone else is unchanged: a stranger, signed or not, still gets the 404 the artist asked for. Ownership is read from the recovered wallet rather than the user_id query param behind myId. user_id is the caller's own claim; it happens to be verified on this route today only because the route sits off authMiddleware's advisory- user_id allowlist, and an artist's original master should not depend on that list continuing to exclude it. Also fix the served filename for the case this now makes reachable: with no orig_file_cid the bytes are the mp3 transcode, so the name must not carry the uploaded file's extension - a .wav name on mp3 bytes is a file most editors refuse to open. Co-Authored-By: Claude Opus 5 <noreply@anthropic.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
Michael has flagged twice (June 25, today) that artists can't download their own tracks. Both reported tracks —
kapyo x artikko - pasionaria(Rpd38wj) andElequence - Novalunosis(r2Xp9aY) — haveis_downloadable = false.GET /v1/tracks/{id}/downloadservestrack.Download, anddbv1.TracksKeyedonly populates that field whenrawTrack.IsDownloadableis true. There is no owner exception, so the edit page's Download File button — the one paired with Replace File, which exists precisely so an artist can retrieve what they uploaded — 404s for the owner and surfaces as the generic "Something went wrong. Please check your connection and storage and try again."79 of 100 sampled trending tracks have downloads off, which matches the "most all tracks" in the report. The public download path itself is healthy: every sampled
is_downloadabletrack returns206anonymously.The original file is still there —
GET /v1/tracks/Rpd38wj/inspect?original=truereports a 63 MBaudio/waveblob on the content node. Nothing was lost; the API just refused to sign a link to it for the person who uploaded it.Fix
When
track.Downloadis nil, fall back to signing a link for a requester who proves — with the wallet signature already on the request — that they own the track or hold a grant on the account that does. Everyone else is unchanged: a stranger, signed or not, still gets the 404 the artist asked for by leaving downloads off.Ownership is read from the recovered wallet rather than the
user_idquery param behindmyId.user_idis the caller's own claim; it happens to be verified on this route today only because the route sits offauthMiddleware's advisory-user_idallowlist, and an artist's original master should not depend on that list continuing to exclude it.Also fixes the served filename for a case this change makes reachable: with no
orig_file_cidthe bytes are the mp3 transcode, so the name must not carry the uploaded file's extension — a.wavname on mp3 bytes is a file most editors refuse to open.Tests
api/v1_track_download_test.gocovers owner, manager-with-grant, anonymous, another wallet, anduser_idspoofing both unsigned and signed by a stranger, plus the mp3 filename fallback. Full./api/...suite passes (TestSearchneeds Elasticsearch, unrelated).🤖 Generated with Claude Code