| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Add `redirect_to_back_or_default`
|
| |
| |
| |
| |
| |
| |
| | |
Applications that use `redirect_to :back` can be forced to 500 by
clients that do not send the HTTP `Referer` (sic) header.
`redirect_back` requires the user to consider this possibility up front
and avoids this trivially-caused application error.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`redirect_to :back` is a somewhat common pattern in Rails apps, but it
is not completely safe. There are a number of circumstances where HTTP
referrer information is not available on the request. This happens often
with bot traffic and occasionally to user traffic depending on browser
security settings.
When there is no referrer available on the request, `redirect_to :back`
will raise `ActionController::RedirectBackError`, usually resulting in
an application error.
`redirect_back` takes a required `fallback_location` keyword argument
that specifies the redirect when the referrer information is not
available. This prevents 500 errors caused by
`ActionController::RedirectBackError`.
|
| |
| |
| |
| |
| |
| |
| | |
When this test was run on Windows, the database file would still be in
use, and `File.unlink` would fail. This would cause the temp directory to
be unable to be removed, and error out. By disconnecting the connection
when finished, we can avoid this error.
|
|\ \ |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Use Module.prepend instead of alias_method for Range#to_s
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Don't leak Object constants in core_ext/module/qualified_const
|
| | |/ /
| |/| | |
|
|/ / /
| | |
| | |
| | |
| | | |
"conditionals in the gemfile creates conditional code in the Gemfile.lock.
Since it is checked in the repository I think it is better to avoid it"
|
| | |
| | |
| | |
| | |
| | |
| | | |
bcrypt 3.1.0 doesn't load on Windows. See
https://github.com/codahale/bcrypt-ruby/issues/128
for details.
|
|\ \ \
| | | |
| | | | |
Introduce ApplicationRecord, an Active Record layer supertype
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|
| |_|/
|/| |
| | |
| | |
| | | |
It appears that MRI on Windows can also appear as `:mingw`, if it was
installed via RubyInstaller.
|
|\ \ \
| | | |
| | | | |
Delete dead code comments
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
ActiveSupport::Multibyte::Unicode::Codepoint doesn't support this API
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
platform `:ruby` is only MRI on Linux or Mac. Windows MRI shows up as
`:mswin` or `:mswin64` depending on if it was installed as 32 or 64 bit. I
am unsure if this will cause conflicts with JRuby on Windows, but I don't
have the means to test this at the moment.
|
|\ \ \ \
| | | | |
| | | | | |
Deprecate passing string to define callback.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix a couple of grammatical errors in security.md
|
| | | | | | |
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
Mention the correct way to halt callback chains
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
The previous title was misleading.
[ci skip]
|
|\ \ \ \ \
| | |/ / /
| |/| | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Running railties generated app tests in development env can cause unintended
consequences. The environments are different and tests aren't meant to be
run in development mode.
The changes to the generator exposed this issue where the random test
order in the generated apps could cause problems when those tests are
run in development mode.
Particularly we saw failures in `railties/test/application/rake_test.rb`
generated apps that used the scaffold to create applications and then
run the migration and immediately run the tests. The error we saw was
`ActiveRecord::RecordNotFound: Couldn't find User with 'id'=980190962`
and seemed to only occur if the destroy test ran first. I'm not entirely
sure _why_ this causes that error to be thrown but I believe it is
related to the environments being different.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In Rails 5.1 `ActionController::TestCase` will be moved out of Rails
into it's own gem. Please use `ActionDispatch::IntegrationTest` going
forward.
This changes the generators to use `ActionDispatch::IntegrationTest` and
the required URL setup (rather than symbols) for each of the controller
actions.
Updated fix to #22076.
|
| | | |
| | | |
| | | |
| | | | |
We will wait until 5.1 to make a decision
|
|\ \ \ \
| | | | |
| | | | | |
Allow users to pass flags from database.yml
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix white-space
Add test case demonstrating flags are received by the adapter
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Handle tab in token authentication header.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The HTTP spec allows for LWS to precede the header content, which
could include multiple SP and HT characters. Update the regex used to
match the Token authorization header to account for this, instead of
matching on a single SP.
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html and
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html for the relevant
parts of the specification.
|
| |_|_|/ /
|/| | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
remove extra spaces from deprecation message
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
```
# before
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This
still causes `String`s to be parsed as if they were in `Time.zone`,
and `Time`s to be converted to `Time.zone`.
To keep the old behavior, you must add the following to your initializer:
config.active_record.time_zone_aware_types = [:datetime]
To silence this deprecation warning, add the following:
config.active_record.time_zone_aware_types << :time
```
```
# after
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This
still causes `String`s to be parsed as if they were in `Time.zone`,
and `Time`s to be converted to `Time.zone`.
To keep the old behavior, you must add the following to your initializer:
config.active_record.time_zone_aware_types = [:datetime]
To silence this deprecation warning, add the following:
config.active_record.time_zone_aware_types << :time
```
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Controller-wide fragment cache key prefixes
|
| | | | | | | |
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Introduced in e56c63542780fe2fb804636a875f95cae08ab3f4, `CacheHelper#fragment_cache_key` is a duplicate of `ActionController::Caching::Fragments#fragment_cache_key`.
We now require the view to provide this method on its own (as with `view_cache_dependencies`); `ActionController::Caching::Fragments` exports its version as a `helper_method`.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Add migration versioning via Migration subclasses
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
.. it also showed a deprecation warning, but we obviously needn't retain
that.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.
The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
|