aboutsummaryrefslogtreecommitdiffstats
path: root/activestorage/test/models/variant_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Prevent content type and disposition bypass in storage service URLsRosa Gutierrez2018-11-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.
* Disable variant options when false or nil presentJacob Smith2018-05-211-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Show ImageProcessing macros in a dedicated exampleJanko Marohnić2018-04-231-3/+13
|
* Rename ActiveStorage.processor to .variant_processorJanko Marohnić2018-04-221-4/+4
|
* Use ImageProcessing gem for ActiveStorage variantsJanko Marohnić2018-04-181-12/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Support varying ICO filesGeorge Claghorn2018-02-241-0/+11
| | | | Closes #32096.
* Extract content types from blob dataGeorge Claghorn2018-01-151-1/+1
|
* Extract Analyzable and Representable concernsGeorge Claghorn2018-01-101-1/+1
|
* Restore support for the -layers transformationGeorge Claghorn2018-01-021-0/+8
|
* Add support for combined MiniMagick transformationsRobert Glaser2017-12-221-0/+14
|
* Convert non-web image (e.g. PSD) variants to PNGGeorge Claghorn2017-12-181-9/+19
|
* Restrict variants to variable image blobsGeorge Claghorn2017-12-151-0/+6
|
* Replace variation key use with SHA256 of key to prevent long filenameskhall2017-10-051-0/+5
| | | | | | | If a variant has a large set of options associated with it, the generated filename will be too long, causing Errno::ENAMETOOLONG to be raised. This change replaces those potentially long filenames with a much more compact SHA256 hash. Fixes #30662.
* Preview PDFs and videosGeorge Claghorn2017-09-281-3/+3
|
* Should escape regexp wildcard character `.`Koichi ITO2017-08-141-2/+2
|
* Use frozen string literal in Active StorageKoichi ITO2017-08-121-0/+2
|
* Fix ruby warningsyuuji.yaginuma2017-08-051-3/+3
| | | | | | | | | | This fixes following warnings: ``` test/models/variant_test.rb:11: warning: ambiguous first argument; put parentheses or a space even after `/' operator lib/active_storage/attached/macros.rb:63: warning: instance variable @active_storage_attached_highlights not initialized lib/active_storage/attached/macros.rb:25: warning: instance variable @active_storage_attached_avatar not initialized ```
* Add 'activestorage/' from commit '3f4a7218a4a4923a0e7ce1b2eb0d2888ce30da58'Rafael Mendonça França2017-07-311-0/+27
git-subtree-dir: activestorage git-subtree-mainline: 0d58e7e478e79c2d6b2a39a4444d2a17a903b2a6 git-subtree-split: 3f4a7218a4a4923a0e7ce1b2eb0d2888ce30da58