Ruby-on-rails – Rails validation context

activerecordruby-on-railsruby-on-rails-3validation

I need help with my ActiveRecord model. I have context based validations (mis)using the build-in context options for validations:

validates :foo, :on => :bar, :presence => true

model = Model.new
model.foo = nil
model.valid? # => true
model.save # works as expected

model.valid?(:bar) # => false
model.save(:context => :bar) # fails and returns false

But using my model in a accepts_nested_attributes_for :model and calling parent.save fails (the validation gets called and returns false), any suggestions or solutions?

Still no answer? To explain more about my problem: I have a model called Form which has many Fields. Users should see validation errors on submit, but the form should be saved anyway (with and without errors). There are different types of Fields, each with global validations (to ensure database consistency) and its own specific user-defined validations (to validate user-entered data). So my Fields look someway like that:

 # Global validations, to ensure database consistency
 # If this validations fail, the record should not be saved!
 validates_associated :form, :on => :global
 ...

 # Specific user-defined validations
 # If this validations fail, the record should be saved but marked as invalid. (Which is done by a before_save filter btw.)
 def validate
   validations.each do |validation| # Array of `ActiveModel::Validations`, defined by the user and stored in a hash in the database
     validation.new(:on => :specific).validate(self)
   end
 end

In my controller:

 # def create
 # ...
 form.attributes = params[:form]
 form.save!(:global)
 form.save(:specific)

Is something similar possible in Rails using the built-in functionality? Btw this not my actual code, which is quite complicated. But I hope, you guys will get the idea.

Best Answer

Try conditional validations

class Customer 
  attr_accessor :managing 

  validates_presence_of :first_name
  validates_presence_of :last_name 

  with_options :unless => :managing do |o|
    o.validates_inclusion_of :city, :in=> ["San Diego","Rochester"]
    o.validates_length_of :biography, :minimum => 100 
  end
end

@customer.managing = true
@customer.attributes = params[:customer]
@customer.save

Related Solutions

Ruby-on-rails – accepts_nested_attributes_for child association validation failing

Use :inverse_of and validates_presence_of :parent. This should fix your validation problem.

   class Dungeon < ActiveRecord::Base
     has_many :traps, :inverse_of => :dungeon
   end

   class Trap < ActiveRecord::Base
     belongs_to :dungeon, :inverse_of => :traps
     validates_presence_of :dungeon
   end

http://apidock.com/rails/ActiveModel/Validations/HelperMethods/validates_presence_of

https://github.com/rails/rails/blob/73f2d37505025a446bb5314a090f412d0fceb8ca/activerecord/test/cases/nested_attributes_test.rb

Ruby-on-rails – Understanding the Rails Authenticity Token

What happens

When the user views a form to create, update, or destroy a resource, the Rails app creates a random authenticity_token, stores this token in the session, and places it in a hidden field in the form. When the user submits the form, Rails looks for the authenticity_token, compares it to the one stored in the session, and if they match the request is allowed to continue.

Why it happens

Since the authenticity token is stored in the session, the client cannot know its value. This prevents people from submitting forms to a Rails app without viewing the form within that app itself. Imagine that you are using service A, you logged into the service and everything is ok. Now imagine that you went to use service B, and you saw a picture you like, and pressed on the picture to view a larger size of it. Now, if some evil code was there at service B, it might send a request to service A (which you are logged into), and ask to delete your account, by sending a request to http://serviceA.com/close_account. This is what is known as CSRF (Cross Site Request Forgery).

If service A is using authenticity tokens, this attack vector is no longer applicable, since the request from service B would not contain the correct authenticity token, and will not be allowed to continue.

API docs describes details about meta tag:

CSRF protection is turned on with the protect_from_forgery method, which checks the token and resets the session if it doesn't match what was expected. A call to this method is generated for new Rails applications by default. The token parameter is named authenticity_token by default. The name and value of this token must be added to every layout that renders forms by including csrf_meta_tags in the HTML head.

Notes

Keep in mind, Rails only verifies not idempotent methods (POST, PUT/PATCH and DELETE). GET request are not checked for authenticity token. Why? because the HTTP specification states that GET requests is idempotent and should not create, alter, or destroy resources at the server, and the request should be idempotent (if you run the same command multiple times, you should get the same result every time).

Also the real implementation is a bit more complicated as defined in the beginning, ensuring better security. Rails does not issue the same stored token with every form. Neither does it generate and store a different token every time. It generates and stores a cryptographic hash in a session and issues new cryptographic tokens, which can be matched against the stored one, every time a page is rendered. See request_forgery_protection.rb.

Lessons

Use authenticity_token to protect your not idempotent methods (POST, PUT/PATCH, and DELETE). Also make sure not to allow any GET requests that could potentially modify resources on the server.

EDIT: Check the comment by @erturne regarding GET requests being idempotent. He explains it in a better way than I have done here.

Best Answer

Related Solutions

Ruby-on-rails – accepts_nested_attributes_for child association validation failing

Ruby-on-rails – Understanding the Rails Authenticity Token

Related Topic