Working through the Users and Authentication of Learning Rails book (great book, code needs to be proof-read in a few cases, though), I came across this: There''s still one leftover that may be worth addressing, depending on your security needs. The authorization? method has secured the data, and the view no longer shows the user options they can''t really use, but if a user knows the URL for the edit form, it will still open. It''s a GET request, after all. This is a good reason to make sure that these forms don''t display any information that isn''t publicly available through other means. If this is an issue, it may be worth the effort of adding authorization checks to every controller method that could spring a leak. Any good reason why I do that instead of adding the checks to the view pages, like? <% if current_user.admin? %> <display page> <% else %> <don''t display page> <% end%> - Rilindo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
It would probably be easier to prevent users from viewing those pages using a filter. If you are using AuthenticatedSystem, you might be able to tap into the login_required function. An example filter would be like <.. in your controller class ..> before_filter :login_required, :except => [:show] Hope that helps. On Fri, Jul 24, 2009 at 8:41 PM, Rilindo Foster <rilindo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Working through the Users and Authentication of Learning Rails book (great > book, code needs to be proof-read in a few cases, though), I came across > this: > There''s still one leftover that may be worth addressing, depending on your > security needs. The authorization? method has secured the data, and the > view no longer shows the user options they can''t really use, but if a user > knows the URL for the edit form, it will still open. It''s a GET request, > after all. This is a good reason to make sure that these forms don''t display > any information that isn''t publicly available through other means. If this > is an issue, it may be worth the effort of adding authorization checks to > every controller method that could spring a leak. > > Any good reason why I do that instead of adding the checks to the view > pages, like? > > *<% if current_user.admin? %>* > > *<display page>* > > * > * > > *<% else %>* > > *<don''t display page>* > > * > > <% end%> > > > - Rilindo > > * > > > > >-- ====================Jim http://www.thepeoplesfeed.com/contribute --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hey, that is easier. I''ll have to save this. Thanks! On Jul 24, 2009, at 8:54 PM, James Englert wrote:> It would probably be easier to prevent users from viewing those > pages using a filter. If you are using AuthenticatedSystem, you > might be able to tap into the login_required function. An example > filter would be like > > <.. in your controller class ..> > before_filter :login_required, :except => [:show] > > Hope that helps. > > On Fri, Jul 24, 2009 at 8:41 PM, Rilindo Foster <rilindo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > Working through the Users and Authentication of Learning Rails book > (great book, code needs to be proof-read in a few cases, though), I > came across this: > > There''s still one leftover that may be worth addressing, depending > on your security needs. The authorization? method has secured the > data, and the view no longer shows the user options they can''t > really use, but if a user knows the URL for the edit form, it will > still open. It''s a GET request, after all. This is a good reason to > make sure that these forms don''t display any information that isn''t > publicly available through other means. If this is an issue, it may > be worth the effort of adding authorization checks to every > controller method that could spring a leak. > > Any good reason why I do that instead of adding the checks to the > view pages, like? > > <% if current_user.admin? %> > <display page> > > <% else %> > <don''t display page> > <% end%> > > - Rilindo > > > > > > -- > ====================> Jim > http://www.thepeoplesfeed.com/contribute > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I am using Authlogic for authentification and
rails_authorization_plugin for authorization
when needed, at the beginning of a controller I write
before_filter :require_user # can be also require_no_user to
exclude multi-sessions from same user
before_filter :check_authorization, :except => :index # to
control access
and at the end of the controller , check for the all page access...
can be also per action
# If the user is not authorized, just throw the exception.
def check_authorization
permit "superadmin or administrator" do
return
end
render_403
end
On 25 juil, 03:09, Rilindo Foster
<rili...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Hey, that is easier. I''ll have to save this.
>
> Thanks!
>
> On Jul 24, 2009, at 8:54 PM, James Englert wrote:
>
>
>
> > It would probably be easier to prevent users from viewing those
> > pages using a filter. If you are using AuthenticatedSystem, you
> > might be able to tap into the login_required function. An example
> > filter would be like
>
> > <.. in your controller class ..>
> > before_filter :login_required, :except => [:show]
>
> > Hope that helps.
>
> > On Fri, Jul 24, 2009 at 8:41 PM, Rilindo Foster
<rili...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > wrote:
> > Working through the Users and Authentication of Learning Rails book
> > (great book, code needs to be proof-read in a few cases, though), I
> > came across this:
>
> > There''s still one leftover that may be worth addressing,
depending
> > on your security needs. The authorization? method has secured the
> > data, and the view no longer shows the user options they
can''t
> > really use, but if a user knows the URL for the edit form, it will
> > still open. It''s a GET request, after all. This is a good
reason to
> > make sure that these forms don''t display any information that
isn''t
> > publicly available through other means. If this is an issue, it may
> > be worth the effort of adding authorization checks to every
> > controller method that could spring a leak.
>
> > Any good reason why I do that instead of adding the checks to the
> > view pages, like?
>
> > <% if current_user.admin? %>
> > <display page>
>
> > <% else %>
> > <don''t display page>
> > <% end%>
>
> > - Rilindo
>
> > --
> > ====================> > Jim
> >http://www.thepeoplesfeed.com/contribute