| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
We want the actual order to be very predictable, so it's rightly defined
in code -- not with an on-the-fly tsort.
But we can do the tsort here, and then verify that it matches the
implemented ordering. This way we don't leave future readers guessing
which parts of the ordering are deliberate and which are arbitrary.
|
| |
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
| |
This commit suppressed
`warning: instance variable @session_store not initialized`.
e5a6f7ee9e951dbe0e4e9ea2c0743b4dfb135c57 introduced these
warnings.
|
|\
| |
| |
| | |
Setup default session store internally, no longer through an initializer
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
initializer
- By default the session store will be set to cookie store with
application name as session key.
- Older apps are not affected as they will have the session store
initializer generated by Rails in older versions, and Rails will not
overwrite the session store if it is already set or disabled.
- But new apps will not have the initializer, instead the session store
will be set to cookie store by default.
- Based on comment by DHH here - https://github.com/rails/rails/issues/25181#issuecomment-222312764.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
set to activerecord session store
- Use keyword args as it is possible to use them now.
- The error message for activerecord-session_store gem was added in 1807384.
- But it was added for a code path which gets called when we try to
**access** the session store, not when we **set** it.
- So the test expecting the exception started failing because now the
session store is set via railtie again **after** setting it first with
:active_record_store in the test.
- As the error is not raised while setting the store to
:active_record_store, the store gets overwritten by railtie and when
we access it via `session_store` while building the default middleware
stack, the exception is not raised.
- This commit moves the code for raising the exception to the path where
we try to set the store.
|
|/
|
|
|
|
|
|
|
|
|
| |
by Rails
- We need to ability to check whether the session store it is set or
not so that we can set it ourselves in an internal initializer.
- We can't rely on return value of `config.session_store` as it can
return `nil` when set to `disabled` and we will accidentally override it
and set to default cookie store.
- So introduced new method which just tells us whether it is set or not.
|
| |
|
|
|
|
|
|
|
| |
This will fix the failures fixed by
41488adbb89a09fa96188486f8414842ff28c848
and keep this new option that is semi-private
outside of the generated configurations
|
|
|
|
|
|
|
|
| |
This will make easier to applications that rely on having const_missing
hooks in production upgrade to Rails 5.
This option is going to be remove in the future and the default behavior
will be to disable the dependency loading.
|
|
|
|
|
|
|
|
| |
The /rails/info routes were inaccessible in apps with a catch-all
globbing route, as they were being appended after the globbing route and
would never be matched.
See also ccc3ddb7762bae0df7e2f8d643b19b6a4769d5be.
|
|
|
|
| |
http://edgeguides.rubyonrails.org/api_documentation_guidelines.html#english
|
|\
| |
| |
| |
| | |
prathamesh-sonpatki/add-config-to-deprecation-warning
Add `config` to the deprecation warnings of deprecated config options
|
| | |
|
|/
|
|
|
|
| |
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.
|
|
|
|
| |
Also, make sure to call the +complete+ hooks if +run+ fails.
|
|\
| |
| | |
Added 'config.' to deprecation warning
|
| |
| |
| |
| | |
Misc:
`config.public_file_server.enabled = true` instead `public_file_server.enabled = true`
|
| |
| |
| |
| |
| |
| | |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to provide a way for Action Cable, Sprockets, and possibly
other Rack applications to mark themselves as internal, and to exclude
themselves from the routing inspector, and thus `rails routes` / `rake
routes`.
I think this is the only way to have mounted Rack apps be marked as
internal, within AD/Journey. Another option would be to create an array
of regexes for internal apps, and then to iterate over that everytime a
request comes through. Also, I only had the first `add_route` method set
`internal`'s default to false, to avoid littering it all over the
codebase.
|
|
|
|
|
|
| |
We mostly care about `reload_classes_only_on_change=true`, because
that's the default... and there, we definitely need to wait for the lock
when necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the sole presence of the Listen constant
enabled the evented file watcher (unless listen resorted to
the polling backend).
This way, applications may depend on listen for other stuff
independently of this feature. Also, allows teams with mixed
setups to decide at boot time whether the evented watcher
should be enabled for each particular instance.
|
| |
|
| |
|
| |
|
|
|
|
| |
behavior
|
| |
|
|
|
|
|
| |
Railsties tests are broken with this new update checker so we will use
the old one until we have the tests fixed.
|
|
|
|
| |
Also call it `public_server.index_name` so it'll make more sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the implementation of the file update checker written
by Puneet Agarwal for GSoC 2015 (except for the tiny version
of the listen gem, which was 3.0.2 in the original patch).
Puneet's branch became too out of sync with upstream. This is
the final work in one single clean commit.
Credit goes in the first line using a convention understood
by the contrib app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fix the message by wrapping the value in missing quotes and adding
the missing backtick at the end. Finally, :lipstick: by adding a space
inside the curly braces.
Before:
`config.public_file_server.headers = {'Cache-Control' => public,
max-age=31536000}
Now:
`config.public_file_server.headers = { 'Cache-Control' => 'public,
max-age=31536000' }`
2. Display `static_cache_control` instead of static_cache_control. This
follows what the 2 neighboring methods are doing.
3. Use strip_heredoc to improve the code formatting and readability
like the 2 neighboring methods and wrap to 80 characters.
|
|
|
|
|
|
|
|
| |
As discussed in https://github.com/rails/rails/pull/19135#issuecomment-153385986.
Replaces `serve_static_files` to unify the static options under the `public_file_server` wing.
Deprecates `serve_static_files` accessors, but make them use the newer config internally.
|
|\
| |
| |
| | |
Add basic support for access control headers to ActionDispatch::Static
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now ActionDispatch::Static can accept HTTP headers so that developers
will have control of returning arbitrary headers like
'Access-Control-Allow-Origin' when a response is delivered. They can
be configured through `#config.public_file_server.headers`:
config.public_file_server.headers = {
"Cache-Control" => "public, max-age=60",
"Access-Control-Allow-Origin" => "http://rubyonrails.org"
}
Also deprecate `config.static_cache_control` in favor of
`config.public_file_server.headers`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| |
| |
| |
| |
| |
| | |
Allocating a new middleware proxy in each application configuration and
then merging the app specific config with the global config when the app
is built.
|
| |
| |
| |
| |
| | |
This can still be added to the middleware stack, but is really not
necessary. I'll follow up with a commit that deprecates the constant
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specifically, the "loose upgrades" behaviour that allows us to obtain an
exclusive right to load things while other requests are in progress (but
waiting on the exclusive lock for themselves) prevents us from treating
load & unload interchangeably: new things appearing is fine, but they do
*not* expect previously-present constants to vanish.
We can still use loose upgrades for unloading -- once someone has
decided to unload, they don't really care if someone else gets there
first -- it just needs to be tracked separately.
|
| | |
|
|/
|
|
|
| |
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
| |
|
|
|
|
| |
when true
|