Best way to validate Chained actions?

[Micah Jaffe]

I'm trying to figure out the best[*] way to validate Chained actions  
at various points along the action chain.  By validate, I mean "check  
if the action should proceed or bomb out."  Validation is not the  
same as authentication; I may be logged in but I may not have  
permissions to do certain things.  It may also mean proceeding is not  
possible because there is some bad data introduced in one of the  
links.  Let's take a simple chain where I want to check whether or  
not a user can perform basic CRUD type things on our data.
Given two paths:

/bigthing/<id>
/bigthing/<id>/edit

I was building this chain as:

load-bigthing-data -> check_read -> view
                                  -> check_update -> edit

Now this gets convoluted when I want to act on sub part of bigthing.  
Say we have action paths that resemble something like:

/bigthing/<id>/smallthing/<id_2>
/bigthing/<id>/smallthing/<id_2>/edit

So presumably, I'd try to chain like:

load-bigthing-data -> check_read -> load-smallthing-data -> view  
(that's ok)
                                                          ->  
check_update -> edit (bad)

check_update is chained between check_read and edit, so I either need  
to create a new (duplicated) check_update for smallthing edit or  
preferably come up with something better.

I wasn't very happy with the permissions validation being wedged in  
as a link in this action chain.  I think a better solution might be  
to use attributes and custom Actions, but I'm still trying to wrap my  
head around that possibility.  The best solution would bomb out  
before doing any more processing in further actions (i.e. doing it as  
part of an 'end' action is not preferable).

Thoughts?

thanks,
Micah

[*] Best = laziest to code + cleanest to extent + easiest to understand


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[J. Shirley]

On 9/12/07, Micah Jaffe <micah@...> wrote:

I'm trying to figure out the best[*] way to validate Chained actions
at various points along the action chain.  By validate, I mean "check
if the action should proceed or bomb out."  Validation is not the
same as authentication; I may be logged in but I may not have
permissions to do certain things.  It may also mean proceeding is not
possible because there is some bad data introduced in one of the
links.  Let's take a simple chain where I want to check whether or
not a user can perform basic CRUD type things on our data.
Given two paths:

/bigthing/<id>
/bigthing/<id>/edit

I was building this chain as:

load-bigthing-data -> check_read -> view
                                  -> check_update -> edit

Now this gets convoluted when I want to act on sub part of bigthing.
Say we have action paths that resemble something like:

/bigthing/<id>/smallthing/<id_2>
/bigthing/<id>/smallthing/<id_2>/edit

So presumably, I'd try to chain like:

load-bigthing-data -> check_read -> load-smallthing-data -> view
(that's ok)
                                                          ->
check_update -> edit (bad)

check_update is chained between check_read and edit, so I either need
to create a new (duplicated) check_update for smallthing edit or
preferably come up with something better.

I wasn't very happy with the permissions validation being wedged in
as a link in this action chain.  I think a better solution might be
to use attributes and custom Actions, but I'm still trying to wrap my
head around that possibility.  The best solution would bomb out
before doing any more processing in further actions (i.e. doing it as
part of an 'end' action is not preferable).

Thoughts?

thanks,
Micah

[*] Best = laziest to code + cleanest to extent + easiest to understand


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

Sounds like you want Authorization (Catalyst::Plugin::Authorization)

http://search.cpan.org/search?query=Catalyst%3A%3APlugin%3A%3AAuthorization

Easy to extend and implement :)

-J

--
J. Shirley :: jshirley@... :: Killing two stones with one bird...
http://www.toeat.com
_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Christopher H. Laco]

Micah Jaffe wrote:

> I'm trying to figure out the best[*] way to validate Chained actions at
> various points along the action chain.  By validate, I mean "check if
> the action should proceed or bomb out."  Validation is not the same as
> authentication; I may be logged in but I may not have permissions to do
> certain things.  It may also mean proceeding is not possible because
> there is some bad data introduced in one of the links.  Let's take a
> simple chain where I want to check whether or not a user can perform
> basic CRUD type things on our data.
> Given two paths:
>
> /bigthing/<id>
> /bigthing/<id>/edit
>
> I was building this chain as:
>
> load-bigthing-data -> check_read -> view
>                                  -> check_update -> edit
>
> Now this gets convoluted when I want to act on sub part of bigthing.
> Say we have action paths that resemble something like:
>
> /bigthing/<id>/smallthing/<id_2>
> /bigthing/<id>/smallthing/<id_2>/edit

This brings me to a related question that always bugs the hell out of me
about using Chained.

Right now, if you use PathPrefix
(http://use.perl.org/~LTjake/journal/31738), you end up with a
controller that can be subclassed and renamed without changing any code.

In other words, ::BigThing could be renamed to MyThing, the chained uri
follow suit from /bigthing/ to /smallthing/ and everyone is happy.

The minute you add a child class into the mix (SmallThing), you have to
 hardcode Chained in SmallThing with the name/private/path pointing to
BigThing.

Now, renaming BigThing breaks SmallThing. That sucks and I have no idea
how to fix that to make subclassing/renaming with a parent/child level
of Chained happy.

Sure, you could put all of the SmallThing chained methods into the
BigThing class, but now the method names in that class for the
SmallThing actions dirty up the class somewhat.

If any of that made sense, I'm sorry. :-)
It just bugs me that the elegantness of using PathPrefix in Chained goes
to hell when you want to attach another child level into the mix.

It also, just may be too earily in the am for me to thing without coffee.

-=Chris




_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Matt S Trout-2]

On Thu, Sep 13, 2007 at 08:41:24AM -0400, Christopher H. Laco wrote:

> Micah Jaffe wrote:
> > I'm trying to figure out the best[*] way to validate Chained actions at
> > various points along the action chain.  By validate, I mean "check if
> > the action should proceed or bomb out."  Validation is not the same as
> > authentication; I may be logged in but I may not have permissions to do
> > certain things.  It may also mean proceeding is not possible because
> > there is some bad data introduced in one of the links.  Let's take a
> > simple chain where I want to check whether or not a user can perform
> > basic CRUD type things on our data.
> > Given two paths:
> >
> > /bigthing/<id>
> > /bigthing/<id>/edit
> >
> > I was building this chain as:
> >
> > load-bigthing-data -> check_read -> view
> >                                  -> check_update -> edit
> >
> > Now this gets convoluted when I want to act on sub part of bigthing.
> > Say we have action paths that resemble something like:
> >
> > /bigthing/<id>/smallthing/<id_2>
> > /bigthing/<id>/smallthing/<id_2>/edit
>
> This brings me to a related question that always bugs the hell out of me
> about using Chained.
>
> Right now, if you use PathPrefix
> (http://use.perl.org/~LTjake/journal/31738), you end up with a
> controller that can be subclassed and renamed without changing any code.
>
> In other words, ::BigThing could be renamed to MyThing, the chained uri
> follow suit from /bigthing/ to /smallthing/ and everyone is happy.
>
> The minute you add a child class into the mix (SmallThing), you have to
>  hardcode Chained in SmallThing with the name/private/path pointing to
> BigThing.

Somebody needs to implement :Chained(../something).

Given the number of things I'm working on atm, it's unlikely to be me.

Patches welcome :)

--
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/                    http://www.shadowcat.co.uk/ 

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/