Hi,
As I''ve understood in Rails 2.0 it is easy to separate application
functionality for different roles. Like for admins:
map.namespace(:admin) do |admin|
admin.resources :products,
:collection => { :inventory => :get },
:member => { :duplicate => :post },
:has_many => [ :tags, :images, :variants ]
end
But then there is also some other ways where user roles are checked in
the controllers for example to give, or not, access to some parts of the
application.
----------
The question: are these two approaches conflicting? Are they meant for
the same purpose? Is there a more appropriate way (yeah depends on the
app but anyway...)
I''m now using restful_authentication plugin for basic login
functionality. But that doesn''t have roles in place. It seems I could
use RESTful acl to add roles. But I''m having problems with it and
instructions available are really poor. Plus "ruby script/plugin install
http://restful-acl.googlecode.com/svn/tags/restful_acl" fails...
In resume I have some resources and some of the actions belong to the
admin. But I think that just having two roles (admin and normal user)
would be to limited so I want to choose something that I can extend
later on easily.
Any recommendations?
Good tutorials for Rails 2.0 on this area?
Thank you people.
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Namespaced controllers and role based access control (RBAC) are two
different things.
Using a namespaced admin controller is useful for displaying different
views to admin and regular users. Using RBAC alone, you can limit who
has access to certain areas of the site, and you can potentially
create different interfaces for admin and regular users, but then
they''ll be using the same view template, which will be littered with
conditionals such as :
<% admin_content do %>
<%= link_to(''Delete user'', ...) %>
<% end %>
and your controllers will need to return different results depending
upon the role of the currently logged in user, such as:
orders_controller.rb
def index
if @user.is_admin?
@orders = Order.find(:all, ...)
else
@order = @user.orders
end
end
I much prefer to use namespaced controllers which will then give me:
app/views/orders # public views
app/views/admin/orders # admin only views
app/controllers/orders_controller.rb # public controller methods
app/controllers/admin/orders_controller.rb # for admins only
This also leads to a clear distinction between admin areas and public
areas, which should help reduce the possibility of making a mistake in
regards to who has access to what.
And to install the restful_acl plugin, just check it out using svn
into your vendors directory:
svn co http://restful-acl.googlecode.com/svn/tags/restful_acl
or use piston and import it
Mike
On 2/29/08, comopasta Gr
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:>
> Hi,
>
> As I''ve understood in Rails 2.0 it is easy to separate
application
> functionality for different roles. Like for admins:
>
> map.namespace(:admin) do |admin|
> admin.resources :products,
> :collection => { :inventory => :get },
> :member => { :duplicate => :post },
> :has_many => [ :tags, :images, :variants ]
> end
>
> But then there is also some other ways where user roles are checked in
> the controllers for example to give, or not, access to some parts of the
> application.
>
> ----------
>
> The question: are these two approaches conflicting? Are they meant for
> the same purpose? Is there a more appropriate way (yeah depends on the
> app but anyway...)
>
> I''m now using restful_authentication plugin for basic login
> functionality. But that doesn''t have roles in place. It seems I
could
> use RESTful acl to add roles. But I''m having problems with it and
> instructions available are really poor. Plus "ruby script/plugin
install
> http://restful-acl.googlecode.com/svn/tags/restful_acl" fails...
>
> In resume I have some resources and some of the actions belong to the
> admin. But I think that just having two roles (admin and normal user)
> would be to limited so I want to choose something that I can extend
> later on easily.
>
> Any recommendations?
> Good tutorials for Rails 2.0 on this area?
>
> Thank you people.
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Mike thanks for the reply and clarifications. I kind of like more the namespaces as well. And I see it quite clear when we have just normal users and admin. But what if we have more role types? Say Normal users (just view), Contibutors (can view and edit), Admin (can do anything). Do we manage it with more namespaces or do we end up having to use namespaces, RBAC and a mix of both? If we need a mix then it might be clearer to just use RBAC(?). Thanks again. Cheers. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
In a current project, I have admins, moderators and users. I use only a single namespace for admins and then I give moderators access to certain parts of the admin interface using RBAC, and allow them to modify portions of the site using conditional blocks with RBAC. I could''ve created another moderators namespace, but I didn''t feel there were enough differences between moderator and admin access to warrant an entirely new set of views and controllers. For example, both admins and moderators can view a list of users (which will be implemented in the admin/users/index action) but only admins can delete users. I''d be interested to hear how others have implemented this.. Did they use more namespaces, or a combination? I think a namespaced controller is good when there''s a very clear distinction between the different levels of access, such as between an admin and a regular user, since the views and requirements of each will be quite different. For the other roles, it''s less clear, and this is where it''s probably good to use a combination approach. Mike On 2/29/08, comopasta Gr <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Mike thanks for the reply and clarifications. > > I kind of like more the namespaces as well. And I see it quite clear > when we have just normal users and admin. > > But what if we have more role types? Say Normal users (just view), > Contibutors (can view and edit), Admin (can do anything). > > Do we manage it with more namespaces or do we end up having to use > namespaces, RBAC and a mix of both? If we need a mix then it might be > clearer to just use RBAC(?). > > Thanks again. > > Cheers. > > -- > > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Feb 29, 3:27 pm, comopasta Gr <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I''m now using restful_authentication plugin for basic login > functionality. But that doesn''t have roles in place. It seems I could > use RESTful acl to add roles. But I''m having problems with it and > instructions available are really poor. Plus "ruby script/plugin installhttp://restful-acl.googlecode.com/svn/tags/restful_acl" fails...This url is confirmed as working. What do you feel is missing from the documentation? I would be more than happy to update it if I''ve missed something useful ;) --~--~---------~--~----~------------~-------~--~----~ 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 just recently tried to move my admin stuff into a namespace. It seemed like a really good way to go, but I think I am missing something in two areas. 1. I had problems with the nested access with the tests, and found myself having to redefine paths and locations, without ever quite getting them to run. 2. I cannot figure out where the model sits. By creating nested scaffold resources, the model file was also nested under admin. This was ok for say managing users as a namespaced resource, but I also want to be able to access the users in the normal project namespace. Just cant quite get my head around it. Tonypm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
the namespace is just for your controllers, your models should still be accessed under one namespace. I''ve used a two level namespace for models in the past, but gave up on it after I''d heard that it causes more problems than it solves. Mike On Tue, Mar 4, 2008 at 3:16 AM, tonypm <tonypmartin-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:> > I just recently tried to move my admin stuff into a namespace. It > seemed like a really good way to go, but I think I am missing > something in two areas. > > 1. I had problems with the nested access with the tests, and found > myself having to redefine paths and locations, without ever quite > getting them to run. > > 2. I cannot figure out where the model sits. By creating nested > scaffold resources, the model file was also nested under admin. This > was ok for say managing users as a namespaced resource, but I also > want to be able to access the users in the normal project namespace. > > Just cant quite get my head around it. > > Tonypm > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
We like to have landing pages for our Admin areas... can I still achieve these with this type of namespaced resources admin area? On Feb 29, 4:27 pm, comopasta Gr <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Hi, > > As I''ve understood in Rails 2.0 it is easy to separate application > functionality for different roles. Like for admins: > > map.namespace(:admin) do |admin| > admin.resources :products, > :collection => { :inventory => :get }, > :member => { :duplicate => :post }, > :has_many => [ :tags, :images, :variants ] > end > > But then there is also some other ways where user roles are checked in > the controllers for example to give, or not, access to some parts of the > application. > > ---------- > > The question: are these two approaches conflicting? Are they meant for > the same purpose? Is there a more appropriate way (yeah depends on the > app but anyway...) > > I''m now using restful_authentication plugin for basic login > functionality. But that doesn''t have roles in place. It seems I could > use RESTful acl to add roles. But I''m having problems with it and > instructions available are really poor. Plus "ruby script/plugin installhttp://restful-acl.googlecode.com/svn/tags/restful_acl" fails... > > In resume I have some resources and some of the actions belong to the > admin. But I think that just having two roles (admin and normal user) > would be to limited so I want to choose something that I can extend > later on easily. > > Any recommendations? > Good tutorials for Rails 2.0 on this area? > > Thank you people. > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---