Sample example ->
Before:
prathamesh@Prathameshs-MacBook-Pro-2 blog *$ rails server thin
DEPRECATION WARNING: Passing the Rack server name as a regular argument is deprecated
and will be removed in the next Rails version. Please, use the -u
option instead.
After:
prathamesh@Prathameshs-MacBook-Pro-2 squish_app *$ rails server thin
DEPRECATION WARNING: Passing the Rack server name as a regular argument is deprecated and will be removed in the next Rails version. Please, use the -u option instead.
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
Since b21f50d8ae36d9b50b673579e17bccbe55363b34, requiring active_storage
on its own has failed with the following error:
activestorage/lib/active_storage.rb:55:in `<module:ActiveStorage>': undefined method `minutes' for 5:Integer (NoMethodError)
We need this in order to be able to add this migration for users that
use ActiveStorage during update their apps from Rails 5.2 to Rails 6.0.
Related to #33405
`rake app:update` should update active_storage
`rake app:update` should execute `rake active_storage:update`
if it is used in the app that is being updated.
It will add new active_storage's migrations to users' apps during update Rails.
Context https://github.com/rails/rails/pull/33405#discussion_r204239399
Also, see a related discussion in the Campfire:
https://3.basecamp.com/3076981/buckets/24956/chats/12416418@1236713081
We had a discussion on the Core team and we don't want to expose this information
as a JSON endpoint and not by default.
It doesn't make sense to expose this JSON locally and this controller is only
accessible in dev, so the proposed access from a production app seems off.
This reverts commit 8eaffe7e89719ac62ff29c2e4208cfbeb1cd1c38, reversing
changes made to b6e4305c3bca4c673996d0af9db0f4cfbf50215e.
If there is not a `csrf-token` meta tag in the document, the blob record
XHR was including an `X-CSRF-Token` header set to the string
"undefined." Instead of setting it to undefined, it should not be
included in the absence of a meta tag.
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
Since 06ab7b27ea1c1ab357085439abacdb464f6742bf,
`GCSServiceTest#test_signed_URL_response_headers` is broken.
https://travis-ci.org/rails/rails/jobs/460454477#L7084-L7087
This seems to be due to lack of `content_type` at upload.
This is solved by specifying `conten_type`.
However, since the same content is also tested with `test_upload_with_content_type`,
it will be duplicated content, so I think that can remove `test_signed_URL_response_headers`.
* 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.
