Fix Content-Disposition header not working in Azure Blob storage

What does this MR do and why?

Prior to this commit, files downloaded in Azure Blob Storage would not have a Content-Disposition header sent, which would cause files to be saved with an unfriendly filename. gitlab-fog-azure-rm!25 added support for retrieving this response header by requesting this in the Azure shared access signature (SAS) token. We now patch CarrierWave to send these custom options to the File object.

We drop the dynamic parameter check in the CarrierWave patch since we have a fog-google version that supports the options. Plus, this dynamic parameter doesn't work with mocks since the mocks don't copy the exactly method signature.

Relates to #341061 (closed)

How to set up and validate locally

  1. Get an Azure storage account set up.
  2. Add this to your gdk.yml:
  connection:
    provider: 'AzureRM'
    azure_storage_account_name: 'YOUR ACCOUNT'
    azure_storage_access_key: 'YOUR KEY'
  objects:
    artifacts:
      bucket: uploads
    external_diffs:
      bucket: uploads
    lfs:
      bucket: uploads
    uploads:
      bucket: uploads
    packages:
      bucket: uploads
    dependency_proxy:
      bucket: uploads
    terraform_state:
      bucket: uploads
    pages:
      bucket: uploads
  1. gdk restart gitlab-workhorse and gdk restart rails-web
  2. Upload an image in an issue.
  3. When proxy_download is false, notice the rscd (abbreviation for response content disposition) query parameter in the URL is there.
  4. When proxy_download is true, you can inspect the URL and see a Content-Disposition header:

image

  • Verified AWS and Google still work

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Stan Hu

Merge request reports

Loading