| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| | |
:tada::tada::tada:
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
### Summary
This PR changes .rubocop.yml.
Regarding the code using `if ... else ... end`, I think the coding style
that Rails expects is as follows.
```ruby
var = if cond
a
else
b
end
```
However, the current .rubocop.yml setting does not offense for the
following code.
```ruby
var = if cond
a
else
b
end
```
I think that the above code expects offense to be warned.
Moreover, the layout by autocorrect is unnatural.
```ruby
var = if cond
a
else
b
end
```
This PR adds a setting to .rubocop.yml to make an offense warning and
autocorrect as expected by the coding style.
And this change also fixes `case ... when ... end` together.
Also this PR itself is an example that arranges the layout using
`rubocop -a`.
### Other Information
Autocorrect of `Lint/EndAlignment` cop is `false` by default.
https://github.com/bbatsov/rubocop/blob/v0.51.0/config/default.yml#L1443
This PR changes this value to `true`.
Also this PR has changed it together as it is necessary to enable
`Layout/ElseAlignment` cop to make this behavior.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
pg-1.0.0 is just released and most Gemfiles don't restrict
it's version. But the version is checked when connecting to
the database, which leads to the following error:
Gem::LoadError: can't activate pg (~> 0.18), already activated pg-1.0.0
See also this pg issue:
https://bitbucket.org/ged/ruby-pg/issues/270/pg-100-x64-mingw32-rails-server-not-start
Preparation for pg-1.0 was done in commit f28a331023fab,
but the pg version constraint was not yet relaxed.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Make clear that the files are not to be run for interpreters.
Fixes #23847.
Fixes #30690.
Closes #23878.
|
| |
| |
| |
| | |
Follow up of #31004.
|
| | |
|
| |
| |
| |
| | |
This basically reverts f851e1f705f26d8f92f0fc1b265b20bc389d23cb
|
|\ \
| | |
| | | |
redis-rb 4.0 support
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Use `gem 'redis', '~> 4.0'` for new app Gemfiles
* Loosen Action Cable redis-rb dep to `>= 3.3, < 5`
* Bump redis-namespace for looser Redis version dep
* Avoid using the underlying `redis.client` directly
* Use `Redis.new` instead of `Redis.connect`
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
* When the adapter is missing, raise an exception that points out config
typos and missing Gemfile entries. (We can assume that a non-builtin
adapter was used since these are always available.)
* When loading an adapter raises a LoadError, prefix its error message
to indicate that the adapter is likely missing an optional dependency.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a frontend for some reason tries to unsubscribe from a non existing subscription, the following error is logged:
Could not execute command from ({"command"=>"unsubscribe", "identifier"=>"{\"channel\":\"SomeChannel\"}"}) [NoMethodError - undefined method `unsubscribe_from_channel' for nil:NilClass]
Instead, it will now properly log:
Could not execute command from ({"command"=>"unsubscribe", "identifier"=>"{\"channel\":\"SomeChannel\"}"}) [RuntimeError - Unable to find subscription with identifier: {"channel":"SomeChannel"}]
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't use remove_method or remove_possible_method just before a new
definition: at best the purpose is unclear, and at worst it creates a
race condition.
Instead, prefer redefine_method when practical, and
silence_redefinition_of_method otherwise.
|
| | |
|
| | |
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some examples and guides we are recommending to use code like:
```ruby
verified_user = User.find_by(id: cookies.signed[:user_id])
```
My suggestion is to use instead:
```ruby
verified_user = User.find_by(id: cookies.encrypted[:user_id])
```
which invites users to prefer the "newer" encrypted cookies over the
"legacy" signed cookies.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Adds RedisAdapterTest::AlternateConfiguration to account
for a relatively common alternative setup, as it’s used
as the first example in the
[Redis rubygem](https://github.com/redis/redis-rb#getting-started)
- Supplies original RedisAdapterTest with more complete
redis:// url format by adding a ‘userinfo’ (blank user),
so that it resembles the alternate configuration
- Supplies original EventedRedisAdapterTest with more complete
redis:// url as well
- Adds before_script to start redis-server with password as a daemon
and with explicit defaults copied from the default redis.conf
(Instead of using Travis' default init/upstart scripts for `redis` service)
|
| |
| |
| |
| |
| | |
Users should never publicly be interacting with an instance of this. The instance that comes along with an `AC::Connection::Base` instance (the only thing a user should be working with) is [itself intended to be private](https://github.com/tjschuck/rails/blob/master/actioncable/lib/action_cable/connection/base.rb#L137-L140).
[ci skip]
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Allow a default value to be declared for class_attribute
* Convert to using class_attribute default rather than explicit setter
* Removed instance_accessor option by mistake
* False is a valid default value
* Documentation
|
| |
| |
| |
| |
| |
| | |
".. with __dir__ we can restore order in the Universe." - by @fxn
Related to 5b8738c2df003a96f0e490c43559747618d10f5f
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
This method is repeatedly used throughout the docs (in the [AC::Connection docs](https://github.com/rails/rails/blob/12b684985837bc8ee9ad15c174cf4e07ca82d7c4/actioncable/lib/action_cable/connection/base.rb#L28), the [AC README](https://github.com/rails/rails/blob/12b684985837bc8ee9ad15c174cf4e07ca82d7c4/actioncable/README.md#a-full-stack-example), the [AC Guides](https://github.com/rails/rails/blob/12b684985837bc8ee9ad15c174cf4e07ca82d7c4/guides/source/action_cable_overview.md#connection-setup)), but not actually documented itself and seemingly not supported for public use based on its current `private` status.
This actually makes the method public and documents it. The actual behavior that’s documented here is implemented [here](https://github.com/rails/rails/blob/12b684985837bc8ee9ad15c174cf4e07ca82d7c4/actioncable/lib/action_cable/connection/base.rb#L213-L219), via [this rescuing of the UnauthorizedError](https://github.com/rails/rails/blob/3dd1de8ba4d5862b01e7f5dd3878b21fd98b443b/actioncable/lib/action_cable/connection/base.rb#L172).
The method is [already tested here](https://github.com/rails/rails/blob/25473baf409185638073fe2f016f4b9dda284e50/actioncable/test/connection/authorization_test.rb#L17-L29).
|
| |
|
| |
|
|
|
|
|
| |
Unlike Faye support, it seems a bit too documented to remove without
warning. So, here's a warning.
|
| |
|
| |
|
|
|
| |
Fix missing left bracket in exception message.
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
|
|
|
|
|
|
|
| |
Per https://www.timeanddate.com/counters/firstnewyear.html, it's already
2017 in a lot of places, so we should bump the Rails license years to
2017.
[ci skip]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
reactor_running? will be true just after the thread enters
EventMachine.run; reactor_thread only gets set after the internal
initialize_event_machine method has been called, the C extension is set
up, and it is entering its run loop.
|
|
|
|
|
| |
Need to specify `reload` from turbolinks 5.
Ref: 7225f0bb9fd1d71a7a37b53815c90178cc7319bd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WebSocket always defers the decision to the server, because it didn't
have to deal with legacy compatibility... but the same-origin policy is
still a reasonable default.
Origin checks do not protect against a directly connecting attacker --
they can lie about their host, but can also lie about their origin.
Origin checks protect against a connection from 3rd-party controlled
script in a context where a victim browser's cookies will be passed
along. And if an attacker has breached that protection, they've already
compromised the HTTP session, so treating the WebSocket connection in
the same way seems reasonable.
In case this logic proves incorrect (or anyone just wants to be more
paranoid), we retain a config option to disable it.
|
|\
| |
| |
| | |
Optionally allow ActionCable requests from the same host as origin
|