Conversation
oatkins8
changed the title
| end | ||
|
|
||
| def accessible_blobs | ||
| ActiveStorage::Blob |
There was a problem hiding this comment.
Do we want to use sql in this query? I know it is faster but it is less accessible to everyone. (Not saying don't use sql, asking the question)
There was a problem hiding this comment.
Also, I know this is in draft and not finished so ignore this ;)
There was a problem hiding this comment.
Good shout - just changed it to ActiveRecord 👍
oatkins8
changed the title
oatkins8
force-pushed
the
feature/file-download-endpoint
branch
2 times, most recently
from
8a9bcf5 to
5aa9416
Compare
oatkins8
changed the title
Beacons need to scope file access to only documents attached to their associated topics. The accessible_blobs method provides this authorisation layer by joining through the attachments and beacon_topics associations to ensure beacons cannot access files from topics belonging to other beacons.
Beacons receive a manifest listing files they need, then download each file individually via this endpoint. The controller validates that the requesting beacon has access through its assigned topics and supports resumable downloads via Range headers for reliability on unstable connections.
oatkins8
force-pushed
the
feature/file-download-endpoint
branch
from
5aa9416 to
f8f7b33
Compare
| resources :tags, only: %i[index show] | ||
|
|
||
| namespace :beacons do | ||
| resource :manifest, only: :show |
There was a problem hiding this comment.
Do we introduce manifests API here?
|
|
||
| it "does not return blobs from other beacons' topics" do | ||
| other_blob_ids = other_topic.documents.map(&:blob_id) | ||
| expect(beacon.accessible_blobs.pluck(:id)).not_to include(*other_blob_ids) |
There was a problem hiding this comment.
Looks like this case is already covered by previous test
| b | ||
| end | ||
|
|
||
| let(:raw_key) { beacon; @raw_key } |
There was a problem hiding this comment.
If you need beacon to be called first you can use: let!(:beacon) on line 8
| headers: beacon_auth_headers(raw_key).merge("Range" => "bytes=0-1023") | ||
|
|
||
| expect(response.headers["Content-Range"]).to be_present | ||
| expect(response.headers["Content-Range"]).to match(/bytes 0-1023\/\d+/) |
There was a problem hiding this comment.
With this assumption previous one becomes redundant
| blob = Current.beacon.accessible_blobs.find(params[:id]) | ||
|
|
||
| if request.headers["Range"].present? | ||
| send_blob_byte_range_data(blob, request.headers["Range"]) |
There was a problem hiding this comment.
Where does this method originate?
I see a send_blob_stream in https://api.rubyonrails.org/classes/ActiveStorage/Streaming.html but don't see wher this is defined.
4 participants
What Issue Does This PR Cover, If Any?
Resolves: #568
What Changed? And Why Did It Change?
Beacons need to download documents that are attached to their associated topics. Previously there was no endpoint to serve these files with proper authentication and authorization. This PR adds a files endpoint that allows beacons to download documents only from topics they have access to. The endpoint uses ActiveStorage streaming to support both full file downloads and partial content requests via Range headers, which is important for efficient delivery of large files.
The accessible_blobs method was added to the Beacon model to provide the authorization layer, ensuring beacons can only access documents from their own topics. The namespace was also standardised from beacons to beacon for consistency across the API.
How Has This Been Tested?
Comprehensive request specs cover authentication, authorization, full downloads, Range header support with single and multiple byte ranges, not found scenarios, and cross-beacon authorization checks. Model specs verify the accessible_blobs method correctly scopes files to the beacon's topics.