Blocking/accepting params according to @member.admin?

I have a submission form that displays additional fields if the
logged-in member is an admin. To be secure, I don’t want these
particular params to be accepted at all (when the form is submitted) if
the member isn’t an admin. Any thoughts on how to do this? The model
doesn’t seem the correct place to mess with params (what I want is like
attr_protected, but according to @member.admin). I’m not interested in
having separate views/controllers for basically the same form.


If the parameters are associated with a model, like a submissions
title, dates, etc, they could be edited in the model itself. I have a
model and put all its editing in the validate() method. Even some
control-only parameters (not stored in the DB as member attributes) are
defined in the attr_accessor/acccessible sections, and are passed from
the view. It works well, as I don’t have to worry about any validation
code in the views/controllers. I figure every object validates itself.

If you took this approach, you can try a control-only variable on the
form @member_level which stores the current member level, and have an
accessor for it in the submission model. then add any code in the
validate() method which checks the member_level. This is assuming its
up to the submission to know what each member-level can do to it.

As far as not showing the fields on the view for non-admins, just put
the code in a partial and check it there. You can call the partial
from any controllers view. I have a shared view folder and call it
from different views:
<%= render :partial => ‘shared/top_menu’ %>

One correction to my previous post… I went back and checked the
code… I don’t get the member_level value from the form. Ths would be
insecure as anybody can pass a higher level. I get the from
session[:member_id] and look up the user in the DB and retrieve the
member_level. You can also store it in session[:member_level].





This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs