| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, `read_encrypted_secrets` is set with initializer.
Therefore if refer to `secrets` in config, `read_encrypted_secrets` is false,
so can not get the value of `secrets.yml.enc`.
In order to be able to refer to secrets in config, modified to refer to
`config.read_encrypted_secrets` when calling `secrets`.
Fixes #28618.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
| |
With the exception of what is loaded in active_support/rails,
each file is responsible for its own dependencies. You cannot
rely on runtime order of execution.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 37423e4ff883ad5584bab983aceb4b2b759a1fd8.
Jeremy is right that we shouldn't remove this. The fact is that many
engines are depending on this middleware to be in the default stack.
This ties our hands and forces us to keep the middleware in the stack so
that engines will work. To be extremely clear, I think this is another
smell of "the rack stack" that we have in place. When manipulating
middleware, we should have meaningful names for places in the req / res
lifecycle **not** have engines depend on a particular constant be in a
particular place in the stack. This is a weakness of the API that we
have to figure out a way to address before removing the constant.
As far as timing attacks are concerned, we can reduce the granularity
such that it isn't useful information for hackers, but is still useful
for developers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The runtime header is a potential target for timing attacks since it
returns the amount of time spent on the server (eliminating network
speed). Total time is also not accurate for streaming responses.
The middleware can be added back via:
```ruby
config.middleware.ues ::Rack::Runtime
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Using the string version of the class reference is now deprecated when
referencing middleware. This should be written as a class not as a string.
Deprecation warning that this change fixes:
```
DEPRECATION WARNING: Passing strings or symbols to the middleware
builder is deprecated, please change
them to actual class references. For example:
"ActionDispatch::ShowExceptions" => ActionDispatch::ShowExceptions
```
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a more conservative approach to 2602a49. Also changed the comment to be
more inline with everything else in the file (describing what the config value
is doing and why). People should just read the docs for alternatives.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e0a521cfcd13e4d1f0ae8ab96004289e1c020f71.
Conflicts:
railties/CHANGELOG.md
We expect loggers to quack like stdlib logger. If log4r needs different
level= assignment, using a Logger-quacking wrapper is the way to do it.
Fixes #14114.
|
| |
|
|
|
|
|
|
| |
This prevents Rails from assigning meaningless log levels to third
party loggers like log4r. If `Rails.logger` is not `kind_of?(::Logger)`
we simply assign the `config.log_level` as is.
This bug was introduced by #11665.
|
| |
|
| |
Fix bug when log level of Rails.logger (which was set via config.logger) does not match the config.log_level.
|
| |
|
|
|
|
| |
This reverts commit b7d9d6e2cd5082d269dafbc0316e2107febe1451.
Per discussion with @jeremy and @rubys on Campfire.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the eager load behavior was mostly coupled to
config.cache_classes, however this was suboptimal since in
some environments a developer may want to cache classes but
not necessarily load them all on boot (for example, test env).
This pull request also promotes the use of config.eager_load
set to true by default in production. In the majority of the
cases, this is the behavior you want since it will copy most
of your app into memory on boot (which was also the previous
behavior).
Finally, this fix a long standing Rails bug where it was
impossible to access a model in a rake task when Rails was
set as thread safe.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
production so that PID and timestamp are logged. fixes #5388
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
from Ruby stdlib.
|
| |
|
|
| |
app_reloader_hooks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
logs for a certain block, change the log level for that block.
* ActiveSupport::BufferedLogger#open_log is deprecated. This method should
not have been public in the first place.
* ActiveSupport::BufferedLogger's behavior of automatically creating the
directory for your log file is deprecated. Please make sure to create the
directory for your log file before instantiating.
* ActiveSupport::BufferedLogger#auto_flushing is deprecated. Either set the
sync level on the underlying file handle like this:
f = File.open('foo.log', 'w')
f.sync = true
ActiveSupport::BufferedLogger.new f
Or tune your filesystem. The FS cache is now what controls flushing.
* ActiveSupport::BufferedLogger#flush is deprecated. Set sync on your
filehandle, or tune your filesystem.
|
| |
|
|
| |
production concerns
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To the app developer, this means configuration add in
config/initializers/* will not be executed.
Plugins developers need to special case their initializers that are
meant to be run in the assets group by adding :group => :assets.
Conflicts:
railties/CHANGELOG
railties/test/application/assets_test.rb
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, running code via script/runner would demonstrate
different logging behavior than running the same code via a rake task.
In production mode the script/runner approach would always flush the
logger, but the rake-based approach would not automatically flush the
logger. This discrepancy violates the principle of least surprise, and
it could lead to the loss of important production logging data.
This change removes special-case code in the "runner" command, and
replaces it with a general solution to ensure that the logger gets
flushed at exit. This solution works for "runner", "console", "server",
rake tasks, and any other process that loads the Rails environment.
|
| |
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
| |
method_missing.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without the need for Railtie. Specifically, the following hooks were added:
* before_configuration: this hook is run immediately after the Application class
comes into existence, but before the user has added any configuration. This is
the appropriate place to set configuration for your plugin
* before_initialize: This is run after all of the user's configuration has completed,
but before any initializers have begun (in other words, it runs right after
config/environments/{development,production,test}.rb)
* after_initialize: This is run after all of the initializers have run. It is an
appropriate place for forking in a preforking setup
Each of these hooks may be used via ActiveSupport.on_load(name) { }. In all these cases, the context inside the block will be the Application object. This means that for simple cases, you can use these hooks without needing to create a Railtie.
|
| |
|
|
| |
initializing the application on its own. This fixes [#4492 state:resolved] and also avoids the application being initialized twice in some rake tasks.
|
| | |
|
| | |
|
| | |
|
| | |
|
