| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
ActiveSupport::TestCase now"
This reverts commit 98d0f7ebd34b858f12a12dcf37ae54fdbb5cab64.
|
| |
|
|
| |
It's used everywhere, clean and mature enough
|
| |
|
|
|
|
|
|
|
| |
Assigning to a collection of attachments appends rather than replacing, as in 5.2. Existing 5.2 apps that rely on this behavior will no longer break when they're upgraded to 6.0.
For apps generated on 6.0 or newer, assigning replaces the existing attachments in the collection. #attach should be used to add new attachments to the collection without removing existing ones.
I expect that we'll deprecate the old behavior in 6.1.
Closes #36374.
|
| | |
|
| |\
| |
| | |
ActiveStorage - normalize the hash of transformations
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attaching `::One`
Consider a model with `One` and `Many` attachments configured:
class User < ActiveRecord::Base
has_one_attached :avatar
has_many_attached :highlights
end
=== One Attachment
After attaching `One` attachment (`:avatar`), we can see that the associated
`_blob` record (`:avatar_blob`) still returns as `nil`.
user.avatar.attach(blob)
user.avatar_attachment.present? => true
user.avatar_blob.present? => false # Incorrect!
This is a false negative. It happens because after the attachment and blob
are built:
1. The record already has its `_blob` association loaded, as `nil`
2. the `::Attachment` is associated with the record but the `::Blob` only gets
associated with the `::Attachment`, not the record itself
In reality, the blob does in fact exist. We can verify this as follows:
user.avatar.attach(blob)
user.avatar_attachment.blob.present? => true # Blob does exist!
The fix in this change is to simply assign the `::Blob` when assigning
the `::Attachment`. After this fix is applied, we correctly observe:
user.avatar.attach(blob)
user.avatar_attachment.present? => true
user.avatar_blob.present? => true # Woohoo!
=== Many Attachments
We don't see this issue with `Many` attachments because the `_blob` association
is already loaded as part of attaching more/newer blobs.
user.highlights.attach(blob)
user.highlights_attachments.any? => true
user.highlights_blobs.any? => true
|
| | |
|
| |
|
| |
Accommodate case-insensitive filesystems and database collations.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
since Ruby 2.5
https://bugs.ruby-lang.org/issues/14133
|
| |
|
|
| |
`ActiveStorage::Filename#parameters` was removed by #33829.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |\
| |
| | |
Encode Content-Disposition filenames on send_data and send_file
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`.
```ruby
# frozen_string_literal: true
require "bundler/inline"
gemfile(true) do
source "https://rubygems.org"
gem "benchmark-ips"
end
Benchmark.ips do |x|
x.report('+@') { +"" }
x.report('dup') { "".dup }
x.compare!
end
```
```
$ ruby -v benchmark.rb
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
Warming up --------------------------------------
+@ 282.289k i/100ms
dup 187.638k i/100ms
Calculating -------------------------------------
+@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s
dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s
Comparison:
+@: 6775299.3 i/s
dup: 3320400.7 i/s - 2.04x slower
```
|
| |
|
| |
Do nothing instead of raising an error when it’s called on an attached blob.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
overwrite previous attachments
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the following model definitions:
class User < ApplicationRecord
has_one_attached :avatar
end
class Group < ApplicationRecord
has_one_attached :avatar
end
If you attempt to reflect on the User model's avatar attachment via User.reflect_on_attachment, you could receive a reflection for the Group model's avatar attachment. Fix this by ensuring that each model class uses its own Hash object to track attachment reflections.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't include `ActiveJob::TestHelper` since there is no test that uses it.
Ensure removing of overridden User's methods.
Related to https://github.com/rails/rails/pull/33085#issuecomment-395548563
Module#remove_method is private in Ruby 2.4.
Related to fd0bd1bf682622f064ac437ceee4e1b2a6b6d3b9
|
| |\
| |
| | |
ActiveStorage reflection
|
| | | |
|
| | |
| |
| |
| | |
Add the ability to reflect on the attachments that have been defined using ActiveRecord::Reflection.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Generated attachment getter and setter methods are created within
the model's `GeneratedAssociationMethods` module to allow overriding
and composition using `super`.
Includes tests for new functionality.
Co-authored-by: Josh Susser <josh@hasmanythrough.com>
Co-authored-by: Jamon Douglas <terrildouglas@gmail.com>
|
| |
|
|
| |
[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.
|
| |
|
|
| |
Match other services, which all use a 5 MB chunk size.
|
| |\
| |
| | |
has_(one/many)_attached presence validation
|
