Potentially dangerous attribute available for mass assignment Open
class TeamsUser < ActiveRecord::Base
- Read upRead up
- Exclude checks
Mass assignment is a feature of Rails which allows an application to create a record from the values of a hash.
Example:
User.new(params[:user])
Unfortunately, if there is a user field called admin
which controls administrator access, now any user can make themselves an administrator.
attr_accessible
and attr_protected
can be used to limit mass assignment. However, Brakeman will warn unless attr_accessible
is used, or mass assignment is completely disabled.
There are two different mass assignment warnings which can arise. The first is when mass assignment actually occurs, such as the example above. This results in a warning like
Unprotected mass assignment near line 61: User.new(params[:user])
The other warning is raised whenever a model is found which does not use attr_accessible
. This produces generic warnings like
Mass assignment is not restricted using attr_accessible
with a list of affected models.
In Rails 3.1 and newer, mass assignment can easily be disabled:
config.active_record.whitelist_attributes = true
Unfortunately, it can also easily be bypassed:
User.new(params[:user], :without_protection => true)
Brakeman will warn on uses of without_protection
.
Potentially dangerous attribute available for mass assignment Open
class TeamsUser < ActiveRecord::Base
- Read upRead up
- Exclude checks
Mass assignment is a feature of Rails which allows an application to create a record from the values of a hash.
Example:
User.new(params[:user])
Unfortunately, if there is a user field called admin
which controls administrator access, now any user can make themselves an administrator.
attr_accessible
and attr_protected
can be used to limit mass assignment. However, Brakeman will warn unless attr_accessible
is used, or mass assignment is completely disabled.
There are two different mass assignment warnings which can arise. The first is when mass assignment actually occurs, such as the example above. This results in a warning like
Unprotected mass assignment near line 61: User.new(params[:user])
The other warning is raised whenever a model is found which does not use attr_accessible
. This produces generic warnings like
Mass assignment is not restricted using attr_accessible
with a list of affected models.
In Rails 3.1 and newer, mass assignment can easily be disabled:
config.active_record.whitelist_attributes = true
Unfortunately, it can also easily be bypassed:
User.new(params[:user], :without_protection => true)
Brakeman will warn on uses of without_protection
.
Use find_by
instead of where.first
. Open
new_team = AssignmentTeam.where(['id = ? and parent_id = ?', team.team_id, assignment_id]).first
- Read upRead up
- Exclude checks
This cop is used to identify usages of where.first
and
change them to use find_by
instead.
Example:
# bad
User.where(name: 'Bruce').first
User.where(name: 'Bruce').take
# good
User.find_by(name: 'Bruce')
Use find_by
instead of where.first
. Open
TeamsUser.where("team_id = ?", team_id).first
- Read upRead up
- Exclude checks
This cop is used to identify usages of where.first
and
change them to use find_by
instead.
Example:
# bad
User.where(name: 'Bruce').first
User.where(name: 'Bruce').take
# good
User.find_by(name: 'Bruce')
Use find_by
instead of where.first
. Open
team_user = TeamsUser.where('user_id = ? and team_id = ?', user_id, team_id).first
- Read upRead up
- Exclude checks
This cop is used to identify usages of where.first
and
change them to use find_by
instead.
Example:
# bad
User.where(name: 'Bruce').first
User.where(name: 'Bruce').take
# good
User.find_by(name: 'Bruce')
Specify an :inverse_of
option. Open
has_one :team_user_node, foreign_key: 'node_object_id', dependent: :destroy
- Read upRead up
- Exclude checks
This cop looks for has(one|many) and belongsto associations where
ActiveRecord can't automatically determine the inverse association
because of a scope or the options used. This can result in unnecessary
queries in some circumstances. :inverse_of
must be manually specified
for associations to work in both ways, or set to false
to opt-out.
Example:
# good
class Blog < ApplicationRecord
has_many :posts
end
class Post < ApplicationRecord
belongs_to :blog
end
Example:
# bad
class Blog < ApplicationRecord
has_many :posts, -> { order(published_at: :desc) }
end
class Post < ApplicationRecord
belongs_to :blog
end
# good
class Blog < ApplicationRecord
has_many(:posts,
-> { order(published_at: :desc) },
inverse_of: :blog
)
end
class Post < ApplicationRecord
belongs_to :blog
end
# good
class Blog < ApplicationRecord
with_options inverse_of: :blog do
has_many :posts, -> { order(published_at: :desc) }
end
end
class Post < ApplicationRecord
belongs_to :blog
end
Example:
# bad
class Picture < ApplicationRecord
belongs_to :imageable, polymorphic: true
end
class Employee < ApplicationRecord
has_many :pictures, as: :imageable
end
class Product < ApplicationRecord
has_many :pictures, as: :imageable
end
# good
class Picture < ApplicationRecord
belongs_to :imageable, polymorphic: true
end
class Employee < ApplicationRecord
has_many :pictures, as: :imageable, inverse_of: :imageable
end
class Product < ApplicationRecord
has_many :pictures, as: :imageable, inverse_of: :imageable
end
Example:
# bad
# However, RuboCop can not detect this pattern...
class Physician < ApplicationRecord
has_many :appointments
has_many :patients, through: :appointments
end
class Appointment < ApplicationRecord
belongs_to :physician
belongs_to :patient
end
class Patient < ApplicationRecord
has_many :appointments
has_many :physicians, through: :appointments
end
# good
class Physician < ApplicationRecord
has_many :appointments
has_many :patients, through: :appointments
end
class Appointment < ApplicationRecord
belongs_to :physician, inverse_of: :appointments
belongs_to :patient, inverse_of: :appointments
end
class Patient < ApplicationRecord
has_many :appointments
has_many :physicians, through: :appointments
end
@see http://guides.rubyonrails.org/association_basics.html#bi-directional-associations @see http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#module-ActiveRecord::Associations::ClassMethods-label-Setting+Inverses
Prefer each
over for
. Open
for team in users_teams
- Read upRead up
- Exclude checks
This cop looks for uses of the for keyword, or each method. The preferred alternative is set in the EnforcedStyle configuration parameter. An each call with a block on a single line is always allowed, however.
Rename is_team_empty
to team_empty?
. Open
def self.is_team_empty(team_id)
- Read upRead up
- Exclude checks
This cop makes sure that predicates are named properly.
Example:
# bad
def is_even?(value)
end
# good
def even?(value)
end
# bad
def has_value?
end
# good
def value?
end