| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently we sometimes find a redundant begin block in code review
(e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205).
I'd like to enable `Style/RedundantBegin` cop to avoid that, since
rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5
(https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with
that situation than before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Force content-type to binary on service urls for relevant content types
We have a list of content types that must be forcibly served as binary,
but in practice this only means to serve them as attachment always. We
should also set the Content-Type to the configured binary type.
As a bonus: add text/cache-manifest to the list of content types to be
served as binary by default.
* Store content-disposition and content-type in GCS
Forcing these in the service_url when serving the file works fine for S3
and Azure, since these services include params in the signature.
However, GCS specifically excludes response-content-disposition and
response-content-type from the signature, which means an attacker can
modify these and have files that should be served as text/plain attachments
served as inline HTML for example. This makes our attempt to force
specific files to be served as binary and as attachment can be easily
bypassed.
The only way this can be forced in GCS is by storing
content-disposition and content-type in the object metadata.
* Update GCS object metadata after identifying blob
In some cases we create the blob and upload the data before identifying
the content-type, which means we can't store that in GCS right when
uploading. In these, after creating the attachment, we enqueue a job to
identify the blob, and set the content-type.
In other cases, files are uploaded to the storage service via direct
upload link. We create the blob before the direct upload, which happens
independently from the blob creation itself. We then mark the blob as
identified, but we have already the content-type we need without having
put it in the service.
In these two cases, then, we need to update the metadata in the GCS
service.
* Include content-type and disposition in the verified key for disk service
This prevents an attacker from modifying these params in the service
signed URL, which is particularly important when we want to force them
to have specific values for security reasons.
* Allow only a list of specific content types to be served inline
This is different from the content types that must be served as binary
in the sense that any content type not in this list will be always
served as attachment but with its original content type. Only types in
this list are allowed to be served either inline or as attachment.
Apart from forcing this in the service URL, for GCS we need to store the
disposition in the metadata.
Fix CVE-2018-16477.
|
|
|
|
|
|
|
|
|
| |
The Azure gem uses `Azure::Core::Http::HTTPError` for everything:
checksum mismatch, missing object, network unavailable, and many more.
(https://www.rubydoc.info/github/yaxia/azure-storage-ruby/Azure/Core/Http/HTTPError).
Rescuing that class obscures all sorts of configuration errors. We
should check the type of error in those rescue blocks, and reraise when
needed.
|
|
|
|
|
|
|
| |
cbothner/azure-service-swallowing-all-errors"
This reverts commit b204d167c5cfebd59f771d406178e371811ac43a, reversing
changes made to de6a200f82a3de399fa685d583503bc88dbc5e9f.
|
|
|
|
|
|
|
|
|
| |
The Azure gem uses `Azure::Core::Http::HTTPError` for everything:
checksum mismatch, missing object, network unavailable, and many more.
(https://www.rubydoc.info/github/yaxia/azure-storage-ruby/Azure/Core/Http/HTTPError).
Rescuing that class obscures all sorts of configuration errors. We
should check the type of error in those rescue blocks, and reraise when
needed.
|
|
|
|
|
|
|
|
|
| |
`ActiveStorage::Blob#download` and `ActiveStorage::Blob#open` raise
`ActiveStorage::FileNotFoundError` when the corresponding file is missing
from the storage service. Services translate service-specific missing
object exceptions (e.g. `Google::Cloud::NotFoundError` for the GCS service
and `Errno::ENOENT` for the disk service) into
`ActiveStorage::FileNotFoundError`.
|
|
|
|
|
|
|
| |
Avoid mangling service names that end in S:
"GCS".classify # => "GC"
"GCS".camelize # => "GCS"
|
| |
|
|
|
|
| |
Closes #32530.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes #32193.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file `filename.rb` as mentioned in `require "active_storage/filename"`
belongs to the `app` folder while GCSService belongs to the lib folder.
Looking at the git blame, it was added in commit https://github.com/rails/rails/commit/ccac681122db9747fec9512076772bca345e24b9#diff-bda6a610ef1575b2c8458c96b7f12578
where ActiveStorage::Filename was actually used. But it is no longer
required on master and therefore can be removed.
This allows anyone to use GCSService directly without enabling
ActiveStorage engine.
|
| |
|
|
|
|
| |
References #32703.
|
|
|
|
| |
Match other services, which all use a 5 MB chunk size.
|
| |
|
|
|
|
|
|
|
|
| |
Aws::S3::Object#get returns a response with object content wrapped in an
in-memory StringIO object. StringIO#read will return a copy of the
content, which is not necessary because we can return the content
directly using StringIO#string. This halves memory allocation of
S3Service#download, because we remove unnecessary content duplication.
|
|
|
|
|
|
|
| |
Trying to pass the current request down to the service so that it can
create full urls instead of paths makes the API messy so use a model
based on ActiveSupport::CurrentAttributes to provide the current host
to services that need it (primarily the disk service).
|
|
|
|
|
|
|
|
|
| |
If an explicit AWS key pair and/or region is not provided in
config/storage.yml, attempt to use environment variables, shared
credentials, or IAM role credentials. Order of precedence is
determined by the AWS SDK[1].
[1]: https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/setup-config.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The Active Storage service for Azure Storage has an option called `path`
that is ambiguous in meaning. It needs to be set to the primary blob
storage endpoint but that can be determined from the blobs client anyway.
To simplify the configuration this commit removes the `path` option and
gets the endpoint from the blobs client instead.
Closes #32225.
|
|
|
|
| |
Since we started clearing the client-side blob's type in e0867b3, we no longer need to set a blank Content-Type header before issuing the direct upload request. Fixes that Safari 9 would combine the blank Content-Type header with the blank blob type to produce a Content-Type header containing a single comma, invalidating the request.
|
|
|
|
| |
Fixes #32129.
|
|
|
|
| |
Fix customizing the download Content-Type for a directly-uploaded blob via a signed URL. See e8286ee.
|
| |
|
| |
|
|
|
|
|
|
|
| |
* If it raise error `Azure::Core::Http::HTTPError`, return `nil` instead of `false` in
`ActiveStorage::Service::AzureStorageService#delete`.
* Other services behave as same as this.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `keyfile` was renamed to `credentials` in `google-cloud-storage` 1.8.0.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/master/google-cloud-storage/CHANGELOG.md#180--2017-11-14
Although `keyfile` can still be used, but it looks like deprecate.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/ddf7b2a856d676316525eb581c1a4cc83ca6097b/google-cloud-storage/lib/google/cloud/storage.rb#L589...L590
Therefore, I think that should use `credentials` in newly generated
applications.
Ref: https://github.com/GoogleCloudPlatform/google-cloud-ruby/issues/1802
|
| |
|
| |
|
|
|
| |
Closes #31073.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Relying on the GET request issued first to fetch the file we want to
delete is not enough to avoid this error. If the file is deleted after
our GET request but before the DELETE request we'll get a NotFound error
that after all means that the file is already deleted, so it can be
safely ignored.
|
|
|
|
| |
`content_type` parameter is before `disposition` parameter.
|
| |
|
| |
|
|
|
|
| |
And enable `context_dependent` of Style/BracesAroundHashParameters cop.
|