| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Accommodate case-insensitive filesystems and database collations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
| |
changes
|
|\
| |
| | |
Encode Content-Disposition filenames on send_data and send_file
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attachments exist
The issue #32584 was fixed in #33405 by adding foreign key constraint
to the `active_storage_attachments` table for blobs.
This commit implements fix on app-level in order to ensure that users
can't delete a blob with attachments even if they don't have the foreign key constraint.
See a related discussion in the Campfire:
https://3.basecamp.com/3076981/buckets/24956/chats/12416418@1236718899
Note that, we should backport it to `5-2-stable` too.
Related to #33405
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Do nothing instead of raising an error when it’s called on an attached blob.
|
| |
|
| |
|
| |
|
|
|
|
| |
Link to the corresponding ActiveStorage::Blob methods, whose docs more accurately describe their effects. [ci skip]
|
| |
|
| |
|
|
|
|
| |
[ci skip]
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In response to https://github.com/rails/rails/issues/32917
In the current implementation, ActiveStorage passes all options to the underlying processor,
including when a key has a value of false.
For example, passing:
```
avatar.variant(resize: "100x100", monochrome: false, flip: "-90")
```
will return a monochrome image (or an error, pending on ImageMagick configuration) because
it passes `-monochrome false` to the command (but the command line does not allow disabling
flags this way, as usually a user would omit the flag entirely to disable that feature).
This fix only passes those keys forward to the underlying processor if the value responds to
`present?`. In practice, this means that `false` or `nil` will be filtered out before going
to the processor.
One possible use case would be for a user to be able to apply different filters to an avatar.
The code might look something like:
```
variant_options = {
monochrome: params[:monochrome],
resize: params[:resize]
}
avatar.variant(*variant_options)
```
Obviously some sanitization may be beneficial in a real-world scenario, but this type of
configuration object could be used in many other places as well.
- Add removing falsy values from varaints to changelog
- The entirety of #image_processing_transformation inject block was wrapped in `list.tap`
to guard against the default `nil` being returned if no conditional was called.
- add test for explicitly true variant options
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
### Steps to reproduce
Using Rails 5.2.0
When following this example:
http://api.rubyonrails.org/classes/ActiveStorage/Variant.html
`avatar.variant(resize: "100x100", monochrome: true, flip: "-90")`
### Expected behavior
Image should be rendered as flipped.
### Actual behavior
I get an error:
> failed with error: gm mogrify: Unrecognized option (-90).
### Fix:
According to: https://github.com/minimagick/minimagick the option should be called rotate:
`avatar.variant(resize: "100x100", monochrome: true, rotate: "-90")`
So **flip** changed to **rotate**.
### System configuration
**Rails version**: 5.2.0
**Ruby version**: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
|
|
|
|
| |
[David Robertson & George Claghorn]
|
|
|
|
|
|
|
| |
This adds a boolean argument called identify to ActiveStorage::Blob
methods #create_after_upload, #build_after_upload and #upload. It
allows a user to bypass the automatic content_type inference from
the io.
|
| |
|
| |
|
|
|
|
|
| |
This is not true anymore, the image will be downloaded into a temporary
file in a streaming fashion.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and
implements an interface for common image resizing and processing. This
is the canonical image processing gem recommended in [Shrine], and
that's where it developed from. The initial implementation was extracted
from Refile, which also implements on-the-fly transformations.
Some features that ImageProcessing gem adds on top of MiniMagick:
* resizing macros
- #resize_to_limit
- #resize_to_fit
- #resize_to_fill
- #resize_and_pad
* automatic orientation
* automatic thumbnail sharpening
* avoids the complex and inefficient MiniMagick::Image class
* will use "magick" instead of "convert" on ImageMagick 7
However, the biggest feature of the ImageProcessing gem is that it has
an alternative implementation that uses libvips. Libvips is an
alternative to ImageMagick that can process images very rapidly (we've
seen up 10x faster than ImageMagick).
What's great is that the ImageProcessing gem provides the same interface
for both implementations. The macros are named the same, and the libvips
implementation does auto orientation and thumbnail sharpening as well;
only the operations/options specific to ImageMagick/libvips differ. The
integration provided by this PR should work for both implementations.
The plan is to introduce the ImageProcessing backend in Rails 6.0 as the
default backend and deprecate the MiniMagick backend, then in Rails 6.1
remove the MiniMagick backend.
|
|
|
|
|
| |
VariantsController has been merged to RepresentationsController, this
PR fixes outdated references to VariantsController in ActiveStorage documentation.
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
| |
Addresses rails/rails#32247
Add test that checks identify and analyze work in correct order
Break out direct upload test helper
Review changes for direct-upload test helper
|
|
|
|
|
|
| |
mutool is licensed under the Affero GPL, which has strict distribution requirements.
Poppler is licensed under the more liberal GPL, making it a good alternative for those who can't use mutool.
|
|
|
|
| |
Fixes #32129.
|
|
|
|
|
|
|
|
|
| |
Since ActiveStorage::Blob::Representable unifies the idea of previews and
variants under one roof as representation, we may as well have the
controllers follow suit.
Thus ActiveStorage::RepresenationsController enters the fray. I've copied
the old tests for both previews and variants and unified those as well.
|
|
|
|
|
|
|
|
|
| |
`to_prepare` callbacks are run during initialization; using one here
meant that `ActiveStorage::Blob` would be loaded when the app boots,
which would in turn load `ActiveRecord::Base`.
By using a lazy load hook to configure `ActiveStorage::Blob` instead,
we can avoid loading `ActiveRecord::Base` unnecessarily.
|
|
|
|
| |
Closes #32096.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Active Storage is an engine which means its models, jobs and controllers
are autoloaded by Rails rather than Ruby. Unfortunately this means it's
subject to the same gotchas as applications, including this one:
http://guides.rubyonrails.org/v5.1.4/autoloading_and_reloading_constants.html#when-constants-aren-t-missed-qualified-references
On Ruby < 2.5, constants nested under classes can't be autoloaded by
Rails if a top level constant already exists with the same name.
To avoid clashing with constants defined in users' applications or gems,
we can use `require_dependency` to ensure that the nested constants are
loaded before they're used.
|
| |
|
| |
|
| |
|
| |
|