Rails 5.1+ params.require(:post).permit(:files => {}) Rails 5 params.require(:post).tap do |whitelisted| whitelisted[:files] = params[:post][:files].permit! end Rails 4 and below params.require(:post).tap do |whitelisted| whitelisted[:files] = params[:post][:files] end
The behaviour is as follows: Handling of Unpermitted Keys By default parameter keys that are not explicitly permitted will be logged in the development and test environment. In other environments these parameters will simply be filtered out and ignored. Additionally, this behaviour can be changed by changing the config.action_controller.action_on_unpermitted_parameters property in your environment files. If … Read more
My other answer was mostly wrong – new answer. in your params hash, :filename is not associated with another hash, it is associated with an ActiveDispatch::Http::UploadedFile object. Your last code line: def screenshot_params params.require(:screenshot).permit(:title, assets_attributes: :filename) is actually correct, however, the filename attribute is not being allowed since it is not one of the permitted … Read more
Keep in mind that the name you give to your strong parameters (employees, employee_ids, etc.) is largely irrelevant because it depends on the name you choose to submit. Strong parameters work no “magic” based upon naming conventions. The reason https://gist.github.com/leemcalilly/a71981da605187d46d96 is throwing an “Unpermitted parameter” error on ’employee_ids’ is because it is expecting an array … Read more
So the problem you are running into is that the child objects don’t pass validation, right? When the child objects are created at the same time as the parent, the child objects could not possibly know the id of their parent in order to pass validation, it’s true. Here is how you can solve that … Read more
The only situation I have encountered where permitting arbitrary keys in a nested params hash seems reasonable to me is when writing to a serialized column. I’ve managed to handle it like this: class Post serialize :options, JSON end class PostsController < ApplicationController … def post_params all_options = params.require(:post)[:options].try(:permit!) params.require(:post).permit(:title).merge(:options => all_options) end end try … Read more
Update for devise 4.x class ApplicationController < ActionController::Base before_filter :configure_permitted_parameters, if: :devise_controller? protected def configure_permitted_parameters devise_parameter_sanitizer.permit(:sign_up, keys: [:username]) devise_parameter_sanitizer.permit(:sign_in, keys: [:username]) devise_parameter_sanitizer.permit(:account_update, keys: [:username]) end end After adding both gems, devise will work as normal. Update: With the latest version of Devise 3.x, as described at devise#strong-parameters, the authentication key (normally the email field), and … Read more
Update to the latest inherited_resources gem and do this in your controller block: ActiveAdmin.register Blog do #… controller do #… def permitted_params params.permit(:blog => [:name, :description]) # params.permit! # allow all parameters end end end
Rails 4 now has features from the strong_parameters gem built in by default. One no longer has to make calls :as => :admin, nor do you need the attr_accessible :user_attribute, :as => admin in your model. The reason for this is that, by default, rails apps now have ‘security’ for every attribute on models. You … Read more
This is quite late, but I just had this problem myself. I solved it by including both the scalar version and array version in the permit statement, like so: params.require(:photo).permit(:tags, tags: []) FYI – it has to have both in the same permit statement – if you chain them it’ll get thrown out for some … Read more