• Nick Thomas's avatar
    Verify that LFS upload requests are genuine · 5b075413
    Nick Thomas authored
    LFS uploads are handled in concert by workhorse and rails. In normal
    use, workhorse:
    
    * Authorizes the request with rails (upload_authorize)
    * Handles the upload of the file to a tempfile - disk or object storage
    * Validates the file size and contents
    * Hands off to rails to complete the upload (upload_finalize)
    
    In `upload_finalize`, the LFS object is linked to the project. As LFS
    objects are deduplicated across all projects, it may already exist. If
    not, the temporary file is copied to the correct place, and will be
    used by all future LFS objects with the same OID.
    
    Workhorse uses the Content-Type of the request to decide to follow this
    routine, as the URLs are ambiguous. If the Content-Type is anything but
    "application/octet-stream", the request is proxied directly to rails,
    on the assumption that this is a normal file edit request. If it's an
    actual LFS request with a different content-type, however, it is routed
    to the Rails `upload_finalize` action, which treats it as an LFS upload
    just as it would a workhorse-modified request.
    
    The outcome is that users can upload LFS objects that don't match the
    declared size or OID. They can also create links to LFS objects they
    don't really own, allowing them to read the contents of files if they
    know just the size or OID.
    
    We can close this hole by requiring requests to `upload_finalize` to be
    sourced from Workhorse. The mechanism to do this already exists.
    5b075413
lfs_storage_controller.rb 2.1 KB