| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
[Matilda Smeds & Xavier Noria]
|
| | |
|
| |
|
|
|
|
| |
- Also deprecate passing {required} to the model generator.
- Also made sure the global config `belongs_to_required_by_default` is
applied correctly to the model generator for `null: false` option.
|
| | |
|
| |
|
|
| |
See rationale in the warning message included in the patch.
|
| | |
|
| |\
| |
| | |
Rename `connection` option to `database` in `dbconsole` command
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We introduced `connection` option for specifying spec with 1acd9a6464668d4d54ab30d016829f60b70dbbeb.
But now we are using the `database` to specify the same value in other commands.
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/migration/migration_generator.rb#L11
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/model/model_generator.rb#L17
The options provided to the users should be uniform. Since the term
"database" is used in rake task etc, So I want to be able to use it in
`dbconsole` command.
Also I deprecated the `connection` option because I think that it
would be confusing if there are multiple options to specify a same value.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
* add leading `#` before `=>` since hash rocket is valid Ruby code
* add backticks
* remove trailing spaces
* and more
|
| | |
|
| |
|
|
| |
[ci skip] (#35733)
|
| |\
| |
| | |
Add config.disable_sandbox option to Rails console
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A long-running `rails console --sandbox` could cause a database server
to become out-of-memory as it's holding on to changes that happen on the
database.
Given that it's common for Ruby on Rails application with huge
traffic to have separate write database and read database, we should
allow the developers to disable this sandbox option to prevent someone
from accidentally causing the Denial-of-Service on their server.
|
| |/ |
|
| |
|
| |
[Alex Kitchens, Prathamesh Sonpatki]
|
| |
|
|
| |
This allows specifying the environment as would any other rails commands.
|
| |\
| |
| |
| | |
v6.0.0.beta3 release
|
| | |
| |
| |
| |
| |
| |
| | |
* Update RAILS_VERSION
* Bundle
* rake update_versions
* rake changelog:header
|
| |\ \
| | |
| | | |
Add `config.credentials.content_path` and `config.credentials.key_path` to the guide
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the guide
- Fix some typos
Follow up #33962
|
| | |/
|/| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A change to `Rails::Application.config_for` in
https://github.com/rails/rails/pull/33815 and
https://github.com/rails/rails/pull/33882 has altered the behaviour of
the returned object in a breaking manner. Before that change, nested
hashes returned from `config_for` could be accessed using non-symbol keys.
After the change, all keys are recursively symbolized so non-symbol access
fails to read the expected values.
This is a breaking change for any app that might be relying on the
nested hashes returned from `config_for` calls, and thus should be
deprecated before being removed from the codebase.
This commit introduces a temporary `NonSymbolAccessDeprecatedHash` class
that recursively wraps any nested hashes inside the `OrderedOptions`
object returned from `config_for` and issues a deprecation notice when a
non-symbol based access is performed.
This way, apps that are still relying on the ability to access these
nested hashes using non-symbol keys will be able to observe the
deprecation notices and have time to implement changes before non-symbol
access is removed for good.
A CHANGELOG entry is also added to note that non-symbol access to nested
`config_for` hashes is deprecated.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During the development of #33145, I have named a few concepts in the
code as `whitelisted`. We decided to stay away from the term and I
adjusted most of the code afterwards, but here are the cases I forgot to
change.
I also found a case in the API guide that we could have cleaned up as
well.
[ci skip]
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This reverts commit fa791fb8e2a718b5d0430c7ca5a454678dfc192d.
Reason: `server` argument was deprecated in Rails 6.0. Ref: #32058.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
as argument of `run`
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| |
| | |
Add this rake task to test channels only.
We've added `rails test:mailboxes` recently in the same way #34828.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Follow up to: e0d3313
- Revert renames from `encrypted` and `encrypted_file` back to `credentials`.
They might be using our Encrypted* generators but from that level of abstraction
they're still about credentials.
- Same vein: extract a `credentials` method for the `encrypted` local variable. But
don't call it `encrypted` just because it uses that under the hood. It's about
capturing the credentials. It's also useful in `change_credentials_in_system_editor`.
- Remove lots of needless argument passing. We've abstracted content_path and key_path
into methods for a reason, so they should be used. Also spares a conspicuous rename
of content_path into file_path in other methods.
- Reorders private methods so they're grouped into: command building blocks, option
parsers, and the generators.
- Extracts commonality in the credentials application tests. A tad unsure about this.
But I do like that we go with key, content thus matching the command and remove the
yield which isn't really needed.
- Moves test/credentials_test.rb to beneath the test/application directory. It's a
Rails application test, so it should be in there.
- Uses `root.join` — a neat trick gleaned from the tests! — and composes the configuration
private methods such that the building block is below the callers.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add `rails db:system:change` command for changing databases.
```
bin/rails db:system:change --to=postgresql
force config/database.yml
gsub Gemfile
```
The change command copies a template `config/database.yml` with
the target database adapter into your app, and replaces your database
gem with the target database gem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating a new rails application (rails new) using a custom template that
includes gems from an authenticated source, the user has to provide credentials to
bundler.
One way to do this is by exporting environment variables, for example:
export BUNDLE_GITHUB__COM=user:pass: provides credentials for bundler to fetch
gems from github.com.
The problem this PR addresses is that we are currently scrubs all /BUNDLE_.*/
environment variables by wrapping our system calls in Bundler.with_clean_env.
We do this because we don't want our commands executed against the generated project
to use the generator's bundler environment (e.g. our gems): the generated project should
use it's own configuration.
The problem with Bundler.with_clean_env is that, on top of restoring environment
variables to their original state, it also scrubs any /BUNDLE_.*/ variables, which is harmful for authenticated gem sources.
This PR replaces Bundler.with_clean_env with Bundler.with_original_env, which only
restores environment variables to their initial state, without additional scrubbing.
|
| |
|
|
|
|
|
|
|
|
|
| |
We had a discussion on the Core team and we don't want to expose this information
as a JSON endpoint and not by default.
It doesn't make sense to expose this JSON locally and this controller is only
accessible in dev, so the proposed access from a production app seems off.
This reverts commit 8eaffe7e89719ac62ff29c2e4208cfbeb1cd1c38, reversing
changes made to 133e0ba33db5887b047c9ac8233e5b414657bca5.
|
| |
|
| |
Match Action Mailbox, which sets a default queue for each of its two jobs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ActionDispatch::HostAuthorization is a new middleware that prevent
against DNS rebinding and other Host header attacks. By default it is
included only in the development environment with the following
configuration:
Rails.application.config.hosts = [
IPAddr.new("0.0.0.0/0"), # All IPv4 addresses.
IPAddr.new("::/0"), # All IPv6 addresses.
"localhost" # The localhost reserved domain.
]
In other environments, `Rails.application.config.hosts` is empty and no
Host header checks will be done. If you want to guard against header
attacks on production, you have to manually permit the allowed hosts
with:
Rails.application.config.hosts << "product.com"
The host of a request is checked against the hosts entries with the case
operator (#===), which lets hosts support entries of type RegExp,
Proc and IPAddr to name a few. Here is an example with a regexp.
# Allow requests from subdomains like `www.product.com` and
# `beta1.product.com`.
Rails.application.config.hosts << /.*\.product\.com/
A special case is supported that allows you to permit all sub-domains:
# Allow requests from subdomains like `www.product.com` and
# `beta1.product.com`.
Rails.application.config.hosts << ".product.com"
|
| |\
| |
| |
| | |
Remove redundant suffixes on generated helpers.
|
| | | |
|
| |/ |
|
