[Catalyst] Roles and Permissions -- Controller vs View

Hernan Lopes hernanlopes at gmail.com
Tue Dec 28 17:56:34 GMT 2010

try something like this... which is basically
1. verify the roles on the controller
2. build a data structure of displayed content based on roles and set to
3. let the view processes whats in the stash without checking for any roles

in the end its 1 controler and 1 view


sub render_buttons{

my $buttons =3D> {
  managers =3D> {
  (if $user->is_mgr) ? ( edit =3D> 'manager_btn_edit.tt2' ) : (),
//OR something like
//edit =3D> { tt_template =3D> 'manager_btn_edit.tt2', href =3D> '/foo/edit=
', },
  everyone =3D> {
  view =3D> 'manager_btn_view.tt2',

$c->stash(buttons =3D> $buttons);



[% PROCESS $buttons.everyone.view %] [% PROCESS $buttons.managers.edit %]

On Tue, Dec 28, 2010 at 3:35 PM, will trillich
<will.trillich at serensoft.com>wrote:

> In our web app we have lots of features that are predicated upon the user=
> role. For example, a "show" link is available to everyone, but an "edit"
> link is only available to managers.
> Is there a best-practices approach for dealing with this?
> There are two places where user-role is significant -- controller and vie=
> In the controller we use chaining to bounce a user out of an edit method =
> they don't have the right role. And in the view we use lots of [% IF
> c.user.is_mgr %] logic to determine whether or not to display the links.
> (Using user-friendly urls like /thingy/27/edit makes the URL easy to gues=
> so checking inside the controller is a good idea.)
> So right now we're checking for the same thing in the view that we're
> checking for in the controller. The more features that get added that
> require role-checking, the more hairy this gets.
> Is there a way to get all this rolled up into one place? Or at least make
> the view a bit more elegant?
> --
> Failure is not important. How you overcome it, is.
> -- Nick Vujicic
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101228/de0f0=

More information about the Catalyst mailing list