Good evening, there''s a question, I can''t really answer for myself. Let''s assume, I''ve got a rails application for selling cars. A user can create an advertisement by choosing the corresponding model from a table "car_models" and then add additional information. The user should always be able just to _read_ the "car_models" table, not to change it. On the other hand, there''s an assistant who administers the "car_models" table, adding, changing and removing entries. So, where we are? We have our "CarModel" controller with its CRUD methods. And, let''s assume, we have a roled based access control implemented. A normal user is a group member of "STD_USER", for example. So he may only access the "get" oder "read" methods, whatever. The assistant however is member of the group "STD_ADMIN", for example, and has access to all methods of our "CarModel" controller. Although this looks secure, I must confess, that I am concerned. What if the RBAC fails for some reasen? What if a normal user gets accidentally in the admin group? Wouldn''t it be better to separate those functionalities? Let''s say: one administration application and one great wide world application. I''m not convinced myself. How do you handle this? I would be very happy about suggestions. Thank you very much! ms --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Yeah, it''s better to separate them, but you''re still going to be in the same boat as before, really: it''s going to be down to whatever qualifier you decide to split the access levels on. Sent from my iPhone On 30/01/2009, at 9:18 AM, ms <ms-cGBD8117FJM@public.gmane.org> wrote:> > Good evening, > > there''s a question, I can''t really answer for myself. Let''s assume, > I''ve got a rails application for selling cars. A user can create an > advertisement by choosing the corresponding model from a table > "car_models" and then add additional information. The user should > always be able just to _read_ the "car_models" table, not to change > it. On the other hand, there''s an assistant who administers the > "car_models" table, adding, changing and removing entries. > > So, where we are? We have our "CarModel" controller with its CRUD > methods. And, let''s assume, we have a roled based access control > implemented. A normal user is a group member of "STD_USER", for > example. So he may only access the "get" oder "read" methods, > whatever. The assistant however is member of the group "STD_ADMIN", > for example, and has access to all methods of our "CarModel" > controller. > > Although this looks secure, I must confess, that I am concerned. What > if the RBAC fails for some reasen? What if a normal user gets > accidentally in the admin group? > > Wouldn''t it be better to separate those functionalities? Let''s say: > one administration application and one great wide world application. > I''m not convinced myself. How do you handle this? > > I would be very happy about suggestions. > > Thank you very much! > ms > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
gundestrup-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2009-Jan-30 09:03 UTC
Re: Using vs. administer a rails application
Well it all in relations. CarModel controller - has in info. has_many :advertisments All controller actions regarding this model, is garded by if the user is adminnistrator. hence in your user model, you put an bool called "admin". So all actions in the controller if garded with if @user.admin For the advertisment you have: And a belongs_to :carmodel id Carmodel_id -----lots of extra info. Regards svend On Jan 29, 11:18 pm, ms <m...-cGBD8117FJM@public.gmane.org> wrote:> Good evening, > > there''s a question, I can''t really answer for myself. Let''s assume, > I''ve got a rails application for selling cars. A user can create an > advertisement by choosing the corresponding model from a table > "car_models" and then add additional information. The user should > always be able just to _read_ the "car_models" table, not to change > it. On the other hand, there''s an assistant who administers the > "car_models" table, adding, changing and removing entries. > > So, where we are? We have our "CarModel" controller with its CRUD > methods. And, let''s assume, we have a roled based access control > implemented. A normal user is a group member of "STD_USER", for > example. So he may only access the "get" oder "read" methods, > whatever. The assistant however is member of the group "STD_ADMIN", > for example, and has access to all methods of our "CarModel" > controller. > > Although this looks secure, I must confess, that I am concerned. What > if the RBAC fails for some reasen? What if a normal user gets > accidentally in the admin group? > > Wouldn''t it be better to separate those functionalities? Let''s say: > one administration application and one great wide world application. > I''m not convinced myself. How do you handle this? > > I would be very happy about suggestions. > > Thank you very much! > ms--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I use Goldberg (http://wiki.github.com/urbanus/goldberg) to manage this situation. It''s possible to restrict access to controllers/ actions by roles. So you can forbid edit/update to normal users (or on the other hand, forbid everything then allow only view for normal users). But anyway, you are not protected against a configuration mistake or any security bug... Jej --~--~---------~--~----~------------~-------~--~----~ 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 use this approach, too. Moreover I like to separate all admin controllers in their own namespace. Unfortunately in version 2.2 creating scaffold in namespace creates tables with admin_ (if namespace is admin) prefix which is annoying and looks to me as a bug. Also in your controller you can put: before_filter :require_admin where require_admin is a method defined in your application.rb and returns true if current user has admin flag set. You can use before_filter in another way to require admin just for some actions: before_filter :require_admin, :except => [''index''] of before_filter :require_admin, :only => ''destroy'' Regards, Bosko On Jan 30, 10:03 am, "gundest...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <gundest...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Well it all in relations. > CarModel controller - has in info. > has_many :advertisments > > All controller actions regarding this model, is garded by if the user > is adminnistrator. > hence in your user model, you put an bool called "admin". > So all actions in the controller if garded with if @user.admin > > For the advertisment you have: > And a belongs_to :carmodel > > id > Carmodel_id > -----lots of extra info. > > Regards > svend > > On Jan 29, 11:18 pm, ms <m...-cGBD8117FJM@public.gmane.org> wrote: > > > Good evening, > > > there''s a question, I can''t really answer for myself. Let''s assume, > > I''ve got a rails application for selling cars. A user can create an > > advertisement by choosing the corresponding model from a table > > "car_models" and then add additional information. The user should > > always be able just to _read_ the "car_models" table, not to change > > it. On the other hand, there''s an assistant who administers the > > "car_models" table, adding, changing and removing entries. > > > So, where we are? We have our "CarModel" controller with its CRUD > > methods. And, let''s assume, we have a roled based access control > > implemented. A normal user is a group member of "STD_USER", for > > example. So he may only access the "get" oder "read" methods, > > whatever. The assistant however is member of the group "STD_ADMIN", > > for example, and has access to all methods of our "CarModel" > > controller. > > > Although this looks secure, I must confess, that I am concerned. What > > if the RBAC fails for some reasen? What if a normal user gets > > accidentally in the admin group? > > > Wouldn''t it be better to separate those functionalities? Let''s say: > > one administration application and one great wide world application. > > I''m not convinced myself. How do you handle this? > > > I would be very happy about suggestions. > > > Thank you very much! > > ms > >--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
By "this approach" I meant the one Svend gave :-), not the one with Goldberg. Regards, Bosko On Jan 30, 11:34 am, Bosko Ivanisevic <bosko.ivanise...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I use this approach, too. Moreover I like to separate all admin > controllers in their own namespace. Unfortunately in version 2.2 > creating scaffold in namespace creates tables with admin_ (if > namespace is admin) prefix which is annoying and looks to me as a > bug. > > Also in your controller you can put: > > before_filter :require_admin > > where require_admin is a method defined in your application.rb and > returns true if current user has admin flag set. > > You can use before_filter in another way to require admin just for > some actions: > > before_filter :require_admin, :except => [''index''] > > of > > before_filter :require_admin, :only => ''destroy'' > > Regards, > Bosko > > On Jan 30, 10:03 am, "gundest...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <gundest...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > Well it all in relations. > > CarModel controller - has in info. > > has_many :advertisments > > > All controller actions regarding this model, is garded by if the user > > is adminnistrator. > > hence in your user model, you put an bool called "admin". > > So all actions in the controller if garded with if @user.admin > > > For the advertisment you have: > > And a belongs_to :carmodel > > > id > > Carmodel_id > > -----lots of extra info. > > > Regards > > svend > > > On Jan 29, 11:18 pm, ms <m...-cGBD8117FJM@public.gmane.org> wrote: > > > > Good evening, > > > > there''s a question, I can''t really answer for myself. Let''s assume, > > > I''ve got a rails application for selling cars. A user can create an > > > advertisement by choosing the corresponding model from a table > > > "car_models" and then add additional information. The user should > > > always be able just to _read_ the "car_models" table, not to change > > > it. On the other hand, there''s an assistant who administers the > > > "car_models" table, adding, changing and removing entries. > > > > So, where we are? We have our "CarModel" controller with its CRUD > > > methods. And, let''s assume, we have a roled based access control > > > implemented. A normal user is a group member of "STD_USER", for > > > example. So he may only access the "get" oder "read" methods, > > > whatever. The assistant however is member of the group "STD_ADMIN", > > > for example, and has access to all methods of our "CarModel" > > > controller. > > > > Although this looks secure, I must confess, that I am concerned. What > > > if the RBAC fails for some reasen? What if a normal user gets > > > accidentally in the admin group? > > > > Wouldn''t it be better to separate those functionalities? Let''s say: > > > one administration application and one great wide world application. > > > I''m not convinced myself. How do you handle this? > > > > I would be very happy about suggestions. > > > > Thank you very much! > > > ms > >--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> not the one with > Goldberg.You should ;) I think it''s better to group the security concerns in the same place (ie. in golberg) rather than spread them amongs different before_filters. But whatever, the both rely on the skills of the coder! Jej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---