| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| | |
Follow up of 3e81490717a314437f9123d86fa3e9dc55558e95.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sensitive value of database column when call `#inspect`
* Why
Some sensitive data will be exposed in log accidentally by calling `#inspect`, e.g.
```ruby
@account = Account.find params[:id]
payload = { account: @account }
logger.info "payload will be #{ payload }"
```
All the information of `@account` will be exposed in log.
* Solution
Add a class attribute filter_attributes to specify which values of columns shouldn't be exposed.
This attribute equals to `Rails.application.config.filter_parameters` by default.
```ruby
Rails.application.config.filter_parameters += [:credit_card_number]
Account.last.insepct # => #<Account id: 123, credit_card_number: [FILTERED] ...>
```
|
|
|
|
|
|
|
|
|
| |
The rake tasks which became deprecate now does not load the environment.
Therefore, even if the application specifies the behavior of deprecating,
the message is output to stderr ignoring the specification.
It seems that this is not the expected behavior.
We should respect the setting even in the rake tasks.
|
|
|
|
|
|
|
|
|
|
|
| |
Changes the `configs_for` method from using traditional arguments to
using kwargs. This is so I can add the `include_replicas` kwarg without
having to always include `env_name` and `spec_name` in the method call.
`include_replicas` defaults to false because everywhere internally in
Rails we don't want replicas. `configs_for` is for iterating over
configurations to create / run rake tasks, so we really don't ever need
replicas in that case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
|
|\
| |
| | |
Prevent leaking of user's DB credentials on `rails db:create` failure
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue #27852 reports that when `rails db:create` fails, it causes
leaking of user's DB credentials to $stderr.
We print a DB's configuration hash in order to help users more quickly
to figure out what could be wrong with his configuration.
This commit changes message from
"Couldn't create database for #{configuration.inspect}" to
"Couldn't create '#{configuration['database']}' database. Please check your configuration.".
There are two PRs that fixing it #27878, #27879, but they need a bit more work.
I decided help to finish this and added Author of those PRs credit in this commit.
Since it is a security issue, I think we should backport it to
`5-2-stable`, and `5-1-stable`.
Guided by https://edgeguides.rubyonrails.org/maintenance_policy.html#security-issues
Fixes #27852
Closes #27879
Related to #27878
[Alexander Marrs & bogdanvlviv]
|
| |
| |
| |
| | |
I removed the argument so I should remove the conditional too.
|
| |
| |
| |
| | |
The test that used this was updated and it's no longer needed.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We originally did the whole `load_database_yaml` thing because this test
wasn't cooperating and we needed to finish the namespaced rake tasks for
multiple databases.
However, it turns out that YAML can't eval ERB if you don't tell it it's
ERB so you get Pysch parse errors if you're using multi-line ERB or
ERB with conditionals. It's a hot mess.
After trying a few things and thinking it over we decided that it wasn't
worth bandaiding over, the test needed to be improved. The test was
added in #31135 to test that the env is loaded in these tasks. But it
was blowing up because we were trying to read a database name out of the
configuration - however that's not the purpose of this change. We want
to read environment files in the rake tasks, but not in the config
file.
In this PR we changed the test to test what the PR was actually fixing.
We've also deleted the `load_database_yaml` because it caused more
problems than it was worth. This should fix the issues described in
https://github.com/rails/rails/pull/32274#issuecomment-384161057. We
also had these problems at GitHub.
Co-authored-by: alimi <aibrahim2k2@gmail.com>
|
|
|
|
|
|
|
| |
`rake routes` was a public task. Therefore, I think that we should deprecate
it before deleting it.
Related to #32121.
|
|
|
|
|
|
| |
* Invoke Rails::Command within the rake task
* Adds test for calling initializers with 'bin/rake'
* Adds deprecation warning to the rake task
|
|
|
|
|
| |
* Call the Rails::Command::DevCommand in the rake task for dev:cache
* Add deprecation for using `bin/rake` in favor of `bin/rails`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose metadata prevents cookie values from being
copy-pasted and ensures that the cookie is used only
for its originally intended purpose.
The Purpose and Expiry metadata are embedded inside signed/encrypted
cookies and will not be readable on previous versions of Rails.
We can switch off purpose and expiry metadata embedded in
signed and encrypted cookies using
config.action_dispatch.use_cookies_with_metadata = false
if you want your cookies to be readable on older versions of Rails.
|
|
|
|
|
|
|
|
| |
https://github.com/rails/rails/pull/33479 changed `#load_schema` to
prevent displaying schema load on running tests in parallel.
We should test this in order to prevent any regression in the future.
Context https://github.com/rails/rails/pull/33479#discussion_r206870727
|
|
|
|
| |
[Atul Bhosale, Victor Nawothnig]
|
|\
| |
| |
| |
| | |
albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
|
| |
| |
| |
| |
| | |
With this commit, rails commands usage instructions display now +rails+
instead of +bin/rails+ within their recommendations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As discussed in #33203 rails command already looks for, and runs,
bin/rails if it is present.
We were mixing recommendations within guides and USAGE guidelines,
in some files we recommended using rails, in others bin/rails and
in some cases we even had both options mixed together.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After 1996fbe2a3e46ff5698bfa3812afb7f42cdfa899 `rails notes`
isn't the same as `rake notes`.
Since that, we should test `rake routes` instead of `rails notes` in
`railties/test/application/rake/notes_test.rb` file.
So I changed all occurrences of `rails routes` to `rake routes` in that file,
and added assertions about deprecation warning of using `rake notes`.
It will help to figure out that we should remove
`railties/test/application/rake/notes_test.rb` entirely in favour of
`railties/test/commands/notes_test.rb` that was added
in 1996fbe2a3e46ff5698bfa3812afb7f42cdfa899.
|
|/
|
|
| |
Also, added a test that a deprecated message will be output.
|
|
|
|
|
|
| |
`railties/test/isolation/abstract_unit.rb`
Related to #33102
|
|
|
|
|
| |
To prevent redundant `to_s` like https://github.com/rails/rails/pull/32923#discussion_r189460008
automatically in the future.
|
|
|
|
|
|
| |
`config.action_view.finalize_compiled_template_methods`
Follow up of #32418.
|
|
|
|
| |
Follow up of #32605.
|
| |
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
```
$ ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
$ ruby -w -Itest -Ilib -I../activesupport/lib -I../actionpack/lib -I../actionview/lib -I../activemodel/lib test/application/rake/multi_dbs_test.rb
Run options: --seed 28744
F
Failure:
ApplicationTests::RakeTests::RakeMultiDbsTest#test_db:migrate_and_db:structure:dump_and_db:structure:load_works_on_all_databases [test/application/rake/multi_dbs_test.rb:70]:
Expected /CREATE TABLE \"books\"/ to match "CREATE TABLE IF NOT EXISTS \"schema_migrations\" (\"version\" varchar NOT NULL PRIMARY KEY);\nCREATE TABLE IF NOT EXISTS \"ar_internal_metadata\" (\"key\" varchar NOT NULL PRIMARY KEY, \"value\" varchar, \"created_at\" datetime NOT NULL, \"updated_at\" datetime NOT NULL);\nCREATE TABLE IF NOT EXISTS \"books\" (\"id\" integer PRIMARY KEY AUTOINCREMENT NOT NULL, \"title\" varchar, \"created_at\" datetime NOT NULL, \"updated_at\" datetime NOT NULL);\nCREATE TABLE sqlite_sequence(name,seq);\nINSERT INTO \"schema_migrations\" (version) VALUES\n('20180416201805');\n\n\n".
```
|
|
|
|
|
|
|
|
|
| |
I realized I wasn't really testing some of the new rake tasks added so I
built out this new test that uses a multi-db database.yml and allows us
to run create/drop/migrate/schema:dump/schema:load and those that are
namespaced like create:animals. This will make our testing more robust
so we can catch problems quicker and set a good place to add future
tests as these features evolve.
|
|\
| |
| | |
Add custom RuboCop for `assert_not` over `refute`
|
| |
| |
| |
| |
| |
| | |
73e7aab behaved as expected on codeship, failing the build with
exactly these RuboCop violations. Hopefully `rubocop -a` will
have been enough to get a passing build!
|
| |
| |
| |
| | |
Test class name is not `RoutingTest` but `RenderingTest`
|
|\ \
| |/
|/|
| |
| | |
sikachu/move-SourceAnnotationExtractor-under-rails-namespec
Move SourceAnnotationExtractor under Rails module
|
| |
| |
| |
| | |
This class should be under Rails module as it belongs to Rails.
|
|/
|
|
|
|
|
|
|
|
|
| |
If one created Rails 5.1 app and then updated to 5.2,
`secret_key_base` defined in `config/secrets.yml` is ignored for
`development` and `test` environment.
A change in `secret_key_base` in turn breaks
`Rails.application.key_generator`.
If one encrypt data in Rails 5.1, she cannot decrypt it in Rails 5.2
for `development` and `test` environment.
|
|
|
|
| |
Fixes #32248.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using rails routes with small terminal or complicated routes it can be
very difficult to understand where is the element listed in header. psql
had the same issue, that's why they created "expanded mode" you can
switch using `\x` or by starting psql with
```
-x
--expanded
Turn on the expanded table formatting mode. This is equivalent to the \x command.
```
The output is similar to one implemented here for rails routes:
db_user-# \du
List of roles
-[ RECORD 1 ]----------------------------------------------
Role name | super
Attributes | Superuser, Create role, Create DB
Member of | {}
-[ RECORD 2 ]----------------------------------------------
Role name | role
Attributes | Superuser, Create role, Create DB, Replication
Member of | {}
|
|\
| |
| | |
Move rake routes task to rails command
|
| |
| |
| |
| |
| |
| | |
After a discussion with matthewd. It was mentioned that rake tasks need
to be moved to rails command.
See: https://github.com/rails/rails/issues/32117
|
|/
|
|
|
|
| |
With the disabling of TLS 1.0 by most major websites, continuing to run
IE8 or lower becomes increasingly difficult so default to not enforcing
UTF-8 encoding as it's not relevant to other browsers.
|
|
|
|
|
|
|
|
|
| |
`to_prepare` callbacks are run during initialization; using one here
meant that `ActiveStorage::Blob` would be loaded when the app boots,
which would in turn load `ActiveRecord::Base`.
By using a lazy load hook to configure `ActiveStorage::Blob` instead,
we can avoid loading `ActiveRecord::Base` unnecessarily.
|
|
|
|
|
|
|
|
|
| |
Although the spec[1] is defined in such a way that a trailing semi-colon
is valid it also doesn't allow a semi-colon by itself to indicate an
empty policy. Therefore it's easier (and valid) just to omit it rather
than to detect whether the policy is empty or not.
[1]: https://www.w3.org/TR/CSP2/#policy-syntax
|
|
|
|
|
|
| |
Setting up the request environment was accidentally creating a CSP
as a consequence of accessing the option - only set the instance
variable if a block is passed.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 86f7c269073a3a9e6ddec9b957deaa2716f2627d, reversing
changes made to 5ece2e4a4459065b5efd976aebd209bbf0cab89b.
If a policy is set then we should generate it even if it's empty.
However what is happening is that we're accidentally generating an
empty policy when the initializer is commented out by default.
|
|
|
|
|
|
|
|
| |
`Rails.application.config.content_security_policy` is configured with no
policies by default. In this case, Content-Security-Policy header should
not be generated instead of generating the header with no directives.
Firefox also warns "Content Security Policy: Couldn't process unknown
directive ''".
|
|
|
|
| |
Rack::TemfileReaper in default middleware stack for API only apps
|
|\
| |
| | |
Fix custome serializer setting
|
| |
| |
| |
| |
| |
| |
| |
| | |
The serializer should be set up in `after_initialize` so that it work
properly even if the user specifies serializer with initializers.
Also, since `custom_serializers` is `Array`, it needs to be flattened
before setting the value.
|