1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activestorage/lib/active_storage/engine.rb

151 lines
5.6 KiB
Ruby
Raw Normal View History

2017-07-31 16:57:56 -04:00
# frozen_string_literal: true
require "rails"
require "action_controller/railtie"
require "active_job/railtie"
require "active_record/railtie"
2017-07-31 16:57:56 -04:00
require "active_storage"
require "active_storage/previewer/poppler_pdf_previewer"
require "active_storage/previewer/mupdf_previewer"
2017-09-28 16:43:37 -04:00
require "active_storage/previewer/video_previewer"
require "active_storage/analyzer/image_analyzer"
require "active_storage/analyzer/video_analyzer"
require "active_storage/reflection"
module ActiveStorage
class Engine < Rails::Engine # :nodoc:
isolate_namespace ActiveStorage
config.active_storage = ActiveSupport::OrderedOptions.new
config.active_storage.previewers = [ ActiveStorage::Previewer::PopplerPDFPreviewer, ActiveStorage::Previewer::MuPDFPreviewer, ActiveStorage::Previewer::VideoPreviewer ]
config.active_storage.analyzers = [ ActiveStorage::Analyzer::ImageAnalyzer, ActiveStorage::Analyzer::VideoAnalyzer ]
config.active_storage.paths = ActiveSupport::OrderedOptions.new
2019-05-22 15:07:35 -04:00
config.active_storage.queues = ActiveSupport::InheritableOptions.new(mirror: :active_storage_mirror)
2018-01-07 09:02:22 -05:00
config.active_storage.variable_content_types = %w(
image/png
image/gif
image/jpg
image/jpeg
image/pjpeg
image/tiff
image/bmp
image/vnd.adobe.photoshop
image/vnd.microsoft.icon
)
2018-01-07 09:02:22 -05:00
config.active_storage.content_types_to_serve_as_binary = %w(
text/html
text/javascript
image/svg+xml
application/postscript
application/x-shockwave-flash
text/xml
application/xml
application/xhtml+xml
Prevent content type and disposition bypass in storage service URLs * 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.
2018-09-06 10:52:52 -04:00
application/mathml+xml
text/cache-manifest
)
config.active_storage.content_types_allowed_inline = %w(
image/png
image/gif
image/jpg
image/jpeg
image/tiff
image/bmp
Prevent content type and disposition bypass in storage service URLs * 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.
2018-09-06 10:52:52 -04:00
image/vnd.adobe.photoshop
image/vnd.microsoft.icon
application/pdf
2018-01-07 09:02:22 -05:00
)
config.eager_load_namespaces << ActiveStorage
initializer "active_storage.configs" do
2017-07-09 11:04:28 -04:00
config.after_initialize do |app|
ActiveStorage.logger = app.config.active_storage.logger || Rails.logger
ActiveStorage.variant_processor = app.config.active_storage.variant_processor || :mini_magick
ActiveStorage.previewers = app.config.active_storage.previewers || []
ActiveStorage.analyzers = app.config.active_storage.analyzers || []
ActiveStorage.paths = app.config.active_storage.paths || {}
ActiveStorage.routes_prefix = app.config.active_storage.routes_prefix || "/rails/active_storage"
ActiveStorage.draw_routes = app.config.active_storage.draw_routes != false
2018-01-07 09:02:22 -05:00
ActiveStorage.variable_content_types = app.config.active_storage.variable_content_types || []
ActiveStorage.content_types_to_serve_as_binary = app.config.active_storage.content_types_to_serve_as_binary || []
ActiveStorage.service_urls_expire_in = app.config.active_storage.service_urls_expire_in || 5.minutes
Prevent content type and disposition bypass in storage service URLs * 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.
2018-09-06 10:52:52 -04:00
ActiveStorage.content_types_allowed_inline = app.config.active_storage.content_types_allowed_inline || []
ActiveStorage.binary_content_type = app.config.active_storage.binary_content_type || "application/octet-stream"
ActiveStorage.replace_on_assign_to_many = app.config.active_storage.replace_on_assign_to_many || false
2017-07-09 11:04:28 -04:00
end
end
initializer "active_storage.attached" do
require "active_storage/attached"
ActiveSupport.on_load(:active_record) do
include ActiveStorage::Attached::Model
end
end
initializer "active_storage.verifier" do
2017-07-11 12:53:17 -04:00
config.after_initialize do |app|
Add credentials using a generic EncryptedConfiguration class (#30067) * WIP: Add credentials using a generic EncryptedConfiguration class This is sketch code so far. * Flesh out EncryptedConfiguration and test it * Better name * Add command and generator for credentials * Use the Pathnames * Extract EncryptedFile from EncryptedConfiguration and add serializers * Test EncryptedFile * Extract serializer validation * Stress the point about losing comments * Allow encrypted configuration to be read without parsing for display * Use credentials by default and base them on the master key * Derive secret_key_base in test/dev, source it from credentials in other envs And document the usage. * Document the new credentials setup * Stop generating the secrets.yml file now that we have credentials * Document what we should have instead Still need to make it happen, tho. * [ci skip] Keep wording to `key base`; prefer defaults. Usually we say we change defaults, not "spec" out a release. Can't use backticks in our sdoc generated documentation either. * Abstract away OpenSSL; prefer MessageEncryptor. * Spare needless new when raising. * Encrypted file test shouldn't depend on subclass. * [ci skip] Some woordings. * Ditch serializer future coding. * I said flip it. Flip it good. * [ci skip] Move require_master_key to the real production.rb. * Add require_master_key to abort the boot process. In case the master key is required in a certain environment we should inspect that the key is there and abort if it isn't. * Print missing key message and exit immediately. Spares us a lengthy backtrace and prevents further execution. I've verified the behavior in a test app, but couldn't figure the test out as loading the app just exits immediately with: ``` /Users/kasperhansen/Documents/code/rails/activesupport/lib/active_support/testing/isolation.rb:23:in `load': marshal data too short (ArgumentError) from /Users/kasperhansen/Documents/code/rails/activesupport/lib/active_support/testing/isolation.rb:23:in `run' from /Users/kasperhansen/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/minitest-5.10.2/lib/minitest.rb:830:in `run_one_method' from /Users/kasperhansen/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/minitest-5.10.2/lib/minitest/parallel.rb:32:in `block (2 levels) in start' ``` It's likely we need to capture and prevent the exit somehow. Kernel.stub(:exit) didn't work. Leaving it for tomorrow. * Fix require_master_key config test. Loading the app would trigger the `exit 1` per require_master_key's semantics, which then aborted the test. Fork and wait for the child process to finish, then inspect the exit status. Also check we aborted because of a missing master key, so something else didn't just abort the boot. Much <3 to @tenderlove for the tip. * Support reading/writing configs via methods. * Skip needless deep symbolizing. * Remove save; test config reader elsewhere. * Move secret_key_base check to when we're reading it. Otherwise we'll abort too soon since we don't assign the secret_key_base to secrets anymore. * Add missing string literal comments; require unneeded yaml require. * ya ya ya, rubocop. * Add master_key/credentials after bundle. Then we can reuse the existing message on `rails new bc4`. It'll look like: ``` Using web-console 3.5.1 from https://github.com/rails/web-console.git (at master@ce985eb) Using rails 5.2.0.alpha from source at `/Users/kasperhansen/Documents/code/rails` Using sass-rails 5.0.6 Bundle complete! 16 Gemfile dependencies, 72 gems now installed. Use `bundle info [gemname]` to see where a bundled gem is installed. Adding config/master.key to store the master encryption key: 97070158c44b4675b876373a6bc9d5a0 Save this in a password manager your team can access. If you lose the key, no one, including you, can access anything encrypted with it. create config/master.key ``` And that'll be executed even if `--skip-bundle` was passed. * Ensure test app has secret_key_base. * Assign secret_key_base to app or omit. * Merge noise * Split options for dynamic delegation into its own method and use deep symbols to make it work * Update error to point to credentials instead * Appease Rubocop * Validate secret_key_base when reading it. Instead of relying on the validation in key_generator move that into secret_key_base itself. * Fix generator and secrets test. Manually add config.read_encrypted_secrets since it's not there by default anymore. Move mentions of config/secrets.yml to config/credentials.yml.enc. * Remove files I have no idea how they got here. * [ci skip] swap secrets for credentials. * [ci skip] And now, changelogs are coming.
2017-09-11 14:21:20 -04:00
ActiveStorage.verifier = app.message_verifier("ActiveStorage")
2017-07-11 12:53:17 -04:00
end
end
initializer "active_storage.services" do
ActiveSupport.on_load(:active_storage_blob) do
if config_choice = Rails.configuration.active_storage.service
configs = Rails.configuration.active_storage.service_configurations ||= begin
config_file = Pathname.new(Rails.root.join("config/storage.yml"))
raise("Couldn't find Active Storage configuration in #{config_file}") unless config_file.exist?
require "yaml"
require "erb"
YAML.load(ERB.new(config_file.read).result) || {}
rescue Psych::SyntaxError => e
raise "YAML syntax error occurred while parsing #{config_file}. " \
"Please note that YAML must be consistently indented using spaces. Tabs are not allowed. " \
"Error: #{e.message}"
end
ActiveStorage::Blob.service =
2017-07-11 12:53:17 -04:00
begin
ActiveStorage::Service.configure config_choice, configs
2017-07-11 12:53:17 -04:00
rescue => e
raise e, "Cannot load `Rails.config.active_storage.service`:\n#{e.message}", e.backtrace
end
end
end
end
initializer "active_storage.queues" do
config.after_initialize do |app|
if queue = app.config.active_storage.queue
ActiveSupport::Deprecation.warn \
"config.active_storage.queue is deprecated and will be removed in Rails 6.1. " \
"Set config.active_storage.queues.purge and config.active_storage.queues.analysis instead."
2019-05-22 15:07:35 -04:00
ActiveStorage.queues = { purge: queue, analysis: queue, mirror: queue }
else
ActiveStorage.queues = app.config.active_storage.queues || {}
end
end
end
initializer "active_storage.reflection" do
ActiveSupport.on_load(:active_record) do
include Reflection::ActiveRecordExtensions
ActiveRecord::Reflection.singleton_class.prepend(Reflection::ReflectionExtension)
end
end
end
end