| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
| |
It is an application global verifier that can be used to generate and
verify signed messages.
See the documentation of ActiveSupport::MessageVerifier for more
information.
|
| |
|
| |
|
|
|
|
| |
Closes #11381
|
|
|
|
|
| |
This change provides the ability to create a new application with a
configuration which can be specified.
|
|
|
|
|
|
|
| |
The comment on the +env_config+ method is repetitive, likely to get
outdated, and provides no useful information which cannot be gleamed
from the code. I'm therefore removing it. I'm also refactoring the check
for the presence of a secret_token in the configuration.
|
|
|
|
|
|
| |
This reverts commit 7098d6c9ab28931acc9562a00037567609f9e529, reversing
changes made to 9ec2e2ee91568af24e09760a6de2890b89c33f56.
This make some tests fail /cc @wangjohn
|
|\
| |
| | |
Creating a class to build the default middleware stack.
|
| |
| |
| |
| |
| |
| |
| | |
A lot of logic for building the default middleware stack is currently
kept in Application class, but this can be encapsulated and made more
modular by being moved to its own class. Also refactored a couple of the
helper methods.
|
|/
|
|
|
|
|
|
|
| |
Railties.
The comment on the +env_config+ method is repetitive, likely to get
outdated, and provides no useful information which cannot be gleamed
from the code. I'm therefore removing it. I'm also refactoring the check
for the presence of a secret_token in the configuration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A regression was introduced in 5b3bb6, generating route from within an
engine to an another engine resulted in prefixing a path with the
SCRIPT_NAME value.
The regression was caused by the fact that SCRIPT_NAME should be
appended only if it's the SCRIPT_NAME for the application, not if it's
SCRIPT_NAME from the current engine.
closes #10409
|
| |
|
| |
|
|
|
|
| |
Automatically configure cookie-based sessions to use the best cookie jar given the app's config
|
|
|
|
| |
signed cookies generated by Rails 3 to avoid invalidating them when upgrading to Rails 4
|
|
|
|
| |
Check 862389c9537dbb6f65fd26c4325e07607ed437b5 for more background.
|
|
|
|
| |
Check pull request #9789 for more information.
|
| |
|
|
|
|
|
| |
Since the Rack::Lock still exists in development,
let's provide a way to disable it explicitly.
|
| |
|
|
|
|
|
| |
Removing it breaks functionality with gems such as Thinking Sphinx.
This restores it with a deprecation warning. Closes #8551
|
| |
|
| |
|
|
|
|
| |
with Rails 4.0.
|
| |
|
|
|
|
|
|
| |
This allows easy upgrading from the old signed Cookie Store <= 3.2
or the deprecated one in 4.0 (the ones that doesn't use key derivation)
to the new one that signs using key derivation
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Setting the action_dispatch.rack_cache options to true or a hash should
be the way to enable it.
|
| |
|
|
|
|
| |
queues in the classes that use them instead.
|
| |
|
|\
| |
| | |
Add ActiveSupport::KeyGenerator as a simple wrapper around PBKDF2
|
| |
| |
| |
| | |
Available both as an env entry for rack and an instance method on Rails::Application for other uses
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flag was mainly used to add a Rack::Lock middleware to
the stack, but the only scenario the lock is desired is in
development.
If you are deploying on a not-threaded server, the Rack::Lock
does not provide any benefit since you don't have concurrent
accesses. On the other hand, if you are on a threaded server,
you don't want the lock, since it defeats the purpose of using
a threaded server.
If there is someone out there, running on a thread server
and does want a lock, it can be added to your environment
as easy as: `use Rack::Lock`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Closes #7110 there's more work to do on rack-cache issue 69
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to do:
In your configuration:
Rails.queue[:image_queue] = SomeQueue.new
Rails.queue[:mail_queue] = SomeQueue.new
In your app code:
Rails.queue[:mail_queue].push MailJob.new
Both jobs pushed to the same default queue
Rails.queue.push DefaultJob.new
Rails.queue[:default].push DefaultJob.new
|