I'm using Administrate v0.11.0 with search_term textbox,
it works totally fine,
and now I want to add a request parameter my_search_condition_flag which is a boolean flag value that affects search condition.
In my index action of controller,
I added the following line, so that requests with this parameter pass the Strong Parameters validation.
params.permit(:search, :my_search_condition_flag)
The rest of the code in index action is simply copied from ApplicationController.rb of Administrate.
When I make a HTTP request with request parameter my_search_condition_flag=1 ,
my index action is processed just fine,
but HTTP response returns following error:
ActionController::UnpermittedParameters in Admin::MyPage#index
Showing /usr/local/bundle/gems/administrate-0.11.0/app/views/administrate/application/_search.html.erb where line #19 raised:
found unpermitted parameter: :my_search_condition_flag
which is raised from rendering method of search_term textbox inside index.html.erb
<% if show_search_bar %>
<%= render(
"search",
search_term: search_term,
resource_name: display_resource_name(page.resource_name)
) %>
<% end %>
I've already tried the following to my Dashboard class, introduced here:
# -- Overwrite the method to add one more to the permit list
def permitted_attributes
super + [:my_search_condition_flag] # -- Adding our now removed field to thepermitted list
end
How can I tell Administrate to permit a parameter which I want to add?
Do I have to use request body instead? (which I don't want)
You were on the right track there. The exception originates at /app/views/administrate/application/_search.html.erb:19, as you mention. If you look there, you'll see it uses the method clear_search_params, which also uses strong_parameters to allow/deny query params. You can override this with a helper of your own. For example:
module Admin
module ApplicationHelper
def clear_search_params
params.except(:search, :page, :my_required_condition_flag).permit(
:per_page, resource_name => %i[order direction]
)
end
end
end
If you do this, you'll get a new, related error. This time from /app/helpers/administrate/application_helper.rb:48. The method there is called sanitized_order_params, and can be overriden similarly:
module Admin
module ApplicationHelper
# ...
def sanitized_order_params(page, current_field_name)
collection_names = page.item_includes + [current_field_name]
association_params = collection_names.map do |assoc_name|
{ assoc_name => %i[order direction page per_page] }
end
params.permit(:search, :my_required_condition_flag, :id, :page, :per_page, association_params)
end
end
end
And with that, you should be clear of errors.
Admittedly, this is not very nice fix. Ideally Administrate should be providing some better way to override this list of allowed search params. Fancy submitting a PR? ;-)
Related
In an article, a Post controller is created.
But in post_params, params.require requires :post. How this possible or What does it mean that Post controller requires :post
def create
Post.create(post_params)
redirect_to root_path
end
private
def post_params
params.require(:post).permit(:description, :image, :user_id)
end
it's a way Rails Controlling mass-assigment attributes with strong_parameters. this approach forbids mass-assignment of a model attribute from a controller unless that attribute was white-listed
whitelisting is configured using two methos
require, calling require will validate that the parameter is actually present, if not present it will throw an error
permit, calling permit with list of attributes will enable those attributes to "pass through" to model during mass-assignment (this restriction disable code injection by passing unpermitted objects, hashes etc)
from your sample above
params.require(:post).permit(:description, :image)
meaning an instance of post must exist in params and keys/column that allowed to pass through only description and image, if your form passing other field for example :other_description and it's not listed in permit, it will not be saved
The class name :post is required because the controller expects that the parameters are arranged hierarchically under their class names, as one single POST request can yield parameters pertaining to many classes. For example your post description will be available as
params[:post][:description]
In development, it's sometimes useful to inspect the parameters in the browser window. You could use this simple code:
<% if !Rails.env.production? %>
<%= debug(params) %>
<% end %>
I have trouble getting instances variables while overriding Devise::SessionsController.
When an unauthenticated user add an item to its cart, I want to redirect him to the sign in page and apply the addition after he's authenticated.
1 . I pass the item_id as a URL parameters:
localhost:3000/user_accounts/sign_in?item_id=42
I get back in a hidden field in the form, I can have it through the session creation form:
<%= form_for(resource, as: resource_name, url: session_path(resource_name)) do |f| %>
<%= f.hidden_field :item_id, value: params[:item_id] || #item_id %>
...
<% end %>
When Rails starts his form flow, the URL parameters are removed:
Before:
localhost:3000/user_accounts/sign_in?item_id=42
After:
localhost:3000/user_accounts/sign_in
I don't want to loose the item_id when the user fails his authentication, so I ensure #item_id is exposed as an instance variable, so I can inject it back to the form.
However, on failure, Rails(?) / Devise(?) / Warden(?) seems to purge the instance variables (for security reasons?). As a result, #item_id is nil.
Note that works well when the user successfully authenticate (through URL parameters). Also, I use this very same technique in the registration process and it works in both success (URL parameters) and failure (instances variables) case.
Here is my implementation of SessionsController:
class MySessionsController < Devise::SessionsController
def create
#item_id = parse_id(params[:user_account][:item])
super do |account|
add_to_cart(account, #item_id) if #item_id
end
flash.delete(:notice)
end
end
Do you know how I can fix this ?
I am open to alternatives as well.
I was wrong. Rails, Devise and Warden aren't doing shady things to my instance variables. I found out that a redirection was made, explaining why the context was lost.
In the end, I used cookies to fix the problem as #nattfodd suggested it. This was trivial I don't know why I didn't think of it.
class MySessionsController < Devise::SessionsController
def create
item_id = parse_id(cookies.encrypted[:item])
super do |account|
add_to_cart(account, item_id) if item_id
cookies.encrypted[:item] = ""
end
flash.delete(:notice)
end
end
Cleaner, no hack. Good.
I'm trying to create a generic breadcrumbs method in my application controller to assign the breadcrumbs based on the current controller. If I wanted the breadcrumbs for the index of 'Thing', I would need in the view:
<%= breadcrumb :things, things %>
And for edit or show:
<%= breadcrumb :thing, thing %>
Where things is a method in the things controller that returns all things, and thing is a method returning the relevant thing.Both are exposed, and I have in my application layout:
<%= breadcrumb crumb, crumb_resource %>
And in my application controller:
def crumb
return controller_name.singularize.to_sym if edit_or_show_action
controller_name.to_sym
end
def crumb_resource
resource = controller_name
resource = controller_name.singularize if edit_or_show_action
end
def edit_or_show_action
action_name == 'edit' || 'show'
end
This obviously returns a string for crumb_resource, rather than the call to the controller method. From what I can find I believe it has something to do with send, however
controller.send(resource)
obviously doesn't work. How can I convert the string that is returned into a controller method call?
If you're using Gretel, then I think what you might be looking for is this:
def crumb_resource
resource = controller_name
resource = controller_name.singularize if edit_or_show_action
self.instance_variable_get("##{resource}")
end
This is assuming you have stored the relevant resource into #resource_name during the edit/show/index action.
I accepted the answer given as I'm assuming it works for people using instance variables to access models in their view, however in the end this worked for me:
breadcrumb crumb, eval(crumb_resource)
where eval evaluates the string, basically reverse interpolation which sounds pretty cool.
Is there a way to add a hidden input field to all the form that are declared in views in rails. The hidden field needs to have a value passed by a public property in the controller. Essentially I want any form that is given as response by the web server to have an additional hidden input element.
How I do this? Can I override the form_for by some means ? Or can I go with a wrapper of form in partials and enforce everybody to use the partial?
EDIT: OK, my first pass on this didn't work because you can't define a value in an initializer that you're later going to pass in from a controller. So you can go about this one of two ways.
You can define a CustomFormBuilder class - put it in an initializer -
class CustomFormBuilder < ActionView::Helpers::FormBuilder
def submit(value, options = {})
#template.hidden_field_tag(options.delete(:custom_param)) + super
end
end
Then pass the :builder option to form_for
form_for #whatever, builder: CustomFormBuilder
and assuming you call submit(value, options) in the form, where options includes your custom_param, it will be overwritten by the custom method that inserts your hidden field with the value you want.
The alternative is to monkey patch monkey patch FormTagHelper instead:
module ActionView::Helpers::FormTagHelper
def extra_tags_for_form_with_custom_param(html_options)
hidden_field_tag(html_options.delete('custom_param') +
extra_tags_for_form_without_custom_param(html_options)
end
alias_method_chain :extra_tags_for_form, :custom_param
end
That's tweaking the code form_for uses to insert the authenticity token at the top of every form. Now you can pass that custom param to form_for after setting it as an instance variable in the controller:
form_for #object, custom_param: #custom_param do |f|
If you are using Ruby 2.0+ then you can use module prepend instead of the deprecated alias_method_chain e.g.
module CustomParamFormPatch
private
def extra_tags_for_form(html_options)
hidden_field_tag(html_options.delete('custom_param')) +
super
end
end
ActionView::Base.prepend(CustomParamFormPatch)
I have a particular set of views relating to one of my controllers, whereby I want any call to *_path or *_url to append a set of parameters.
Is there some magic method I can override that will let me do this? I have no idea where in the Rails code the *_path or *_url methods are even handled.
Edit for clarity: I'm looking for a way to do this such that I don't have to modify every link in every view where this needs to occur. I don't want every coder who touches this set of views to have to remember to append a parameter to every link they add to the page. The same parameter should be appended automatically. I consider a change to the *_url or *_path call a failure. Similarly, having to override every *_url or *_path call is considered a failure since a new method would have to be added/removed whenever a new link is added/removed.
You can do this by overriding url_for since all the routing methods call it.
module ApplicationHelper
def url_for(options = {})
options.reverse_merge!(#extra_url_for_options) if #extra_url_for_options
super
end
end
Now all you need to do is use a before_filter to set #extra_url_for_options to a hash to force all urls.
class MyController < ApplicationController
before_filter do { #extra_url_for_options = { :format => 'html' } }
end
Note that this will force all links to use the extra options.
Thanks to Samuel's answer, I was able to create a final working solution via a new helper, which I've included below.
module ExampleHelper
def url_for(options={})
options = case options
when String
uri = Addressable::URI.new
uri.query_values = #hash_of_additional_params
options + (options.index('?').nil? ? '?' : '&') + uri.query
when Hash
options.reverse_merge(#hash_of_additional_params)
else
options
end
super
end
end
You can try to use the with_options method. In your view you can do something like
<% with_options :my_param => "my_value" do |append| -%>
<%= append.users_path(1) %>
<% end %>
Assuming you have the users_path of course. my_param=value will be appended to the url
You could make a helper method:
def my_path(p)
"#{p}_path all the parameters I want to append"
end
and in the view use
<%= eval(my_path(whatever)) %>
Eval with give you dynamic scope, so every variable available in your view can be used in the helper. If your parameters are constant you can get rid of eval calls.