I have a model named Division which has_many :courses Bottom line: I need the Ruby way to prevent someone from the id parameter to http://example.com/courses/edit/ so that they don''t hijack another user''s data. The code I have is all over most of the controller methods and it is really clunky. details: Every Division has users who can modify elements only within their own division. so now when someone goes to example.com/courses/edit/9 I need to make sure the course with id of 9 falls within a division that the user has access to. I am trying to prevent the user from modifying parameters to get at someone elses data. I have code like this in nearly all methods in most of my controllers: @course = Course.find(params[:id]) @course = Course.new unless current_user.has_division? (@course.division) I know I am doing it incorrectly, but I can''t find anything to point me to something better. If anyone has an idea, it would be greatly appreciated. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi -- On Fri, 30 Nov 2007, Charles wrote:> > I have a model named Division which has_many :courses > > Bottom line: I need the Ruby way to prevent someone from the id > parameter to http://example.com/courses/edit/ > so that they don''t hijack another user''s data. The code I have is > all > over most of the controller methods and it is really clunky.I don''t know whether there''s a specific Ruby way, but there might be a good Rails way, and it will involve writing Ruby code :-)> details: > Every Division has users who can modify elements only within their > own > division. > so now when someone goes to example.com/courses/edit/9 > > I need to make sure the course with id of 9 falls within a division > that the user has access to. > I am trying to prevent the user from modifying parameters to get at > someone elses data. > > I have code like this in nearly all methods in most of my > controllers: > > @course = Course.find(params[:id]) > @course = Course.new unless current_user.has_division? > (@course.division) > > I know I am doing it incorrectly, but I can''t find anything to point > me to something better. > If anyone has an idea, it would be greatly appreciated.If you can arrange it so that every user has_many :courses (through divisions, perhaps), you could then scope the search like this: @course = current_user.courses.find(params[:id]) That way, no courses outside of that collection will be a candidate for being found. David -- Upcoming training by David A. Black/Ruby Power and Light, LLC: * Intro to Rails, London, UK, December 3-6 (by Skills Matter) See http://www.rubypal.com for details and 2008 announcements! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks for the reply :) I have -lots- of models so I really can''t tie them to the user without making a mess of things. I was trying to get the validation code out of every method, because it is close to the same handful of lines in almost all methods in all models. I really want a plain "before" callback that executes before the methods so that I could prevent data that wasn''t yours from popping up. The other callbacks don''t help because it won''t stop you from seeing data that you shouldn''t. thanks, C. On Nov 30, 3:35 pm, "David A. Black" <dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote:> Hi -- > > On Fri, 30 Nov 2007, Charles wrote: > > > I have a model named Division which has_many :courses > > > Bottom line: I need the Ruby way to prevent someone from the id > > parameter tohttp://example.com/courses/edit/ > > so that they don''t hijack another user''s data. The code I have is > > all > > over most of the controller methods and it is really clunky. > > I don''t know whether there''s a specific Ruby way, but there might be a > good Rails way, and it will involve writing Ruby code :-) > > > > > details: > > Every Division has users who can modify elements only within their > > own > > division. > > so now when someone goes to example.com/courses/edit/9 > > > I need to make sure the course with id of 9 falls within a division > > that the user has access to. > > I am trying to prevent the user from modifying parameters to get at > > someone elses data. > > > I have code like this in nearly all methods in most of my > > controllers: > > > @course = Course.find(params[:id]) > > @course = Course.new unless current_user.has_division? > > (@course.division) > > > I know I am doing it incorrectly, but I can''t find anything to point > > me to something better. > > If anyone has an idea, it would be greatly appreciated. > > If you can arrange it so that every user has_many :courses (through > divisions, perhaps), you could then scope the search like this: > > @course = current_user.courses.find(params[:id]) > > That way, no courses outside of that collection will be a candidate > for being found. > > David > > -- > Upcoming training by David A. Black/Ruby Power and Light, LLC: > * Intro to Rails, London, UK, December 3-6 (by Skills Matter) > Seehttp://www.rubypal.comfor details and 2008 announcements!--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi -- On Fri, 30 Nov 2007, Charles wrote:> > On Nov 30, 3:35 pm, "David A. Black" <dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote: >> Hi -- >> >> On Fri, 30 Nov 2007, Charles wrote: >> >>> I have a model named Division which has_many :courses >> >>> Bottom line: I need the Ruby way to prevent someone from the id >>> parameter tohttp://example.com/courses/edit/ >>> so that they don''t hijack another user''s data. The code I have is >>> all >>> over most of the controller methods and it is really clunky. >> >> I don''t know whether there''s a specific Ruby way, but there might be a >> good Rails way, and it will involve writing Ruby code :-) >> >> >> >>> details: >>> Every Division has users who can modify elements only within their >>> own >>> division. >>> so now when someone goes to example.com/courses/edit/9 >> >>> I need to make sure the course with id of 9 falls within a division >>> that the user has access to. >>> I am trying to prevent the user from modifying parameters to get at >>> someone elses data. >> >>> I have code like this in nearly all methods in most of my >>> controllers: >> >>> @course = Course.find(params[:id]) >>> @course = Course.new unless current_user.has_division? >>> (@course.division) >> >>> I know I am doing it incorrectly, but I can''t find anything to point >>> me to something better. >>> If anyone has an idea, it would be greatly appreciated. >> >> If you can arrange it so that every user has_many :courses (through >> divisions, perhaps), you could then scope the search like this: >> >> @course = current_user.courses.find(params[:id]) >> >> That way, no courses outside of that collection will be a candidate >> for being found. >> > > Thanks for the reply :) > I have -lots- of models so I really can''t tie them to the user without > making a mess of things. > I was trying to get the validation code out of every method, because > it is close to the same handful of lines in almost all methods in all > models. > I really want a plain "before" callback that executes before the > methods so that I could prevent data that wasn''t yours from popping > up. > The other callbacks don''t help because it won''t stop you from seeing > data that you shouldn''t.I''d still recommend looking into how much of the heavy lifting ActiveRecord can do. Model files tend to fare better under the weight of lots of associations, than controller files do under the weight of lots of before_filter... :only => [...] clauses. The latter can get murky in a hurry, whereas associations tend to be self-documenting and make the code more expressive. David -- Upcoming training by David A. Black/Ruby Power and Light, LLC: * Intro to Rails, London, UK, December 3-6 (by Skills Matter) See http://www.rubypal.com for details and 2008 announcements! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
thanks :) I will do that. I see what you are saying. On Nov 30, 4:07 pm, "David A. Black" <dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote:> Hi -- > > > > On Fri, 30 Nov 2007, Charles wrote: > > > On Nov 30, 3:35 pm, "David A. Black" <dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote: > >> Hi -- > > >> On Fri, 30 Nov 2007, Charles wrote: > > >>> I have a model named Division which has_many :courses > > >>> Bottom line: I need the Ruby way to prevent someone from the id > >>> parameter tohttp://example.com/courses/edit/ > >>> so that they don''t hijack another user''s data. The code I have is > >>> all > >>> over most of the controller methods and it is really clunky. > > >> I don''t know whether there''s a specific Ruby way, but there might be a > >> good Rails way, and it will involve writing Ruby code :-) > > >>> details: > >>> Every Division has users who can modify elements only within their > >>> own > >>> division. > >>> so now when someone goes to example.com/courses/edit/9 > > >>> I need to make sure the course with id of 9 falls within a division > >>> that the user has access to. > >>> I am trying to prevent the user from modifying parameters to get at > >>> someone elses data. > > >>> I have code like this in nearly all methods in most of my > >>> controllers: > > >>> @course = Course.find(params[:id]) > >>> @course = Course.new unless current_user.has_division? > >>> (@course.division) > > >>> I know I am doing it incorrectly, but I can''t find anything to point > >>> me to something better. > >>> If anyone has an idea, it would be greatly appreciated. > > >> If you can arrange it so that every user has_many :courses (through > >> divisions, perhaps), you could then scope the search like this: > > >> @course = current_user.courses.find(params[:id]) > > >> That way, no courses outside of that collection will be a candidate > >> for being found. > > > Thanks for the reply :) > > I have -lots- of models so I really can''t tie them to the user without > > making a mess of things. > > I was trying to get the validation code out of every method, because > > it is close to the same handful of lines in almost all methods in all > > models. > > I really want a plain "before" callback that executes before the > > methods so that I could prevent data that wasn''t yours from popping > > up. > > The other callbacks don''t help because it won''t stop you from seeing > > data that you shouldn''t. > > I''d still recommend looking into how much of the heavy lifting > ActiveRecord can do. Model files tend to fare better under the weight > of lots of associations, than controller files do under the weight of > lots of before_filter... :only => [...] clauses. The latter can get > murky in a hurry, whereas associations tend to be self-documenting and > make the code more expressive. > > David > > -- > Upcoming training by David A. Black/Ruby Power and Light, LLC: > * Intro to Rails, London, UK, December 3-6 (by Skills Matter) > Seehttp://www.rubypal.comfor details and 2008 announcements!--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Have a look at this article on The Rails Way: http://therailsway.com/2007/3/26/association-proxies-are-your-friend The first use case for Association Proxies is restricting access. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---