Defining required permissions at the controller request

[Bob Morley <rm...@emforium.com>]

Have been working on some integration between the various modeled objects in
Ofbiz and came across a requirement to allow specification of required
permissions for a controller request.  Effectively what I have been working
on is the ability to walk various model graphs extend behaviour to one model
from the other.  What I have working so far is some extension and clean-up
to the presentment model, control model, and service model including the
ability for these models to accept a visitor.

So far I have only really worked on base visitors that navigate through a
model or crawl from one model to another model.  This has enabled us to
write some interesting unit tests -- for example, by starting with the
controllers I was able to crawl through every screen in the system which
crawled the various soft links to forms, menus, trees, etc.  Failures were
reported in the unit test; so in effect the unit test verifies that you have
not created any bad includes.  From the source I had I only found one error
in the set of Ofbiz screens (lots in our hot-deploy) :)

Other interesting things become possible.  For example, one could get the
entire list of screens (from standard means) and then start with the
controllers they could crawl through all controller requests to the various
presentment artifacts making note of each screen that gets hit (either
directly or from crawling the decorators/include-screens/etc) making note of
each screen found.  In the end you can fail on any defined screens that are
not referenced anywhere in the system.

By far the most interesting thing I am working on, and the reason for this
message, is the ability to apply behaviour from one model to the other. 
Using the current method of setting permissions, we were thinking of
something like this.

a) In general define permissions at the service definition.
b) Between loading the controller requests and storing them in the cache, we
will walk the controller requests to the service defintion; gather up the
permissions; and dynamically apply them to the controller request map.  This
modified model would be cached with new "permission" objects on the
controller requests.

Now while this does not get you very much (failing in the controller is not
much different than failing in the service dispatcher); it does get us to a
point where we can apply a similar pattern when loading / caching the model
screens.  Specifically, if you have created an xml representation of a menu
link when you walk the presentment model and hit that link you can crawl
over to the related controller requests.  This has been cached now with
permissions which you could then apply to the menu link.  In short, if you
do not have permission the menu link now is not rendered.  Again you would
do this crawl at load/cache time and the modified object model would be
cached, so there is no expensive visiting at render time.

Does anyone want to have a dialog about possible community interest in these
set of enhancements?  I am more than willing to explain things further, make
adjustments, packing them up, etc.  Back to the original subject; I can also
piece out the change that gave control requests the ability to define
required permissions (understanding that there is some work underway to
change how permissions are done).
-- 
View this message in context: http://n4.nabble.com/Defining-required-permissions-at-the-controller-request-tp585686p585686.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Defining required permissions at the controller request

[Wickersheimer Jeremy <jw...@opensourcestrategies.com>]

Hi,

This seems very interesting. I would say that the crawler could be a useful tool for 
developers (to begin with), do you have the code available somewhere ?

Also i am guessing you can only get static permissions, what about permission that depend 
on a relationship between the current user and an entity ?

-- 
Wickersheimer Jeremy
On Wednesday 11 November 2009 12:56:11 Bob Morley wrote:
> Have been working on some integration between the various modeled objects
>  in Ofbiz and came across a requirement to allow specification of required
>  permissions for a controller request.  Effectively what I have been
>  working on is the ability to walk various model graphs extend behaviour to
>  one model from the other.  What I have working so far is some extension
>  and clean-up to the presentment model, control model, and service model
>  including the ability for these models to accept a visitor.
> 
> So far I have only really worked on base visitors that navigate through a
> model or crawl from one model to another model.  This has enabled us to
> write some interesting unit tests -- for example, by starting with the
> controllers I was able to crawl through every screen in the system which
> crawled the various soft links to forms, menus, trees, etc.  Failures were
> reported in the unit test; so in effect the unit test verifies that you
>  have not created any bad includes.  From the source I had I only found one
>  error in the set of Ofbiz screens (lots in our hot-deploy) :)
> 
> Other interesting things become possible.  For example, one could get the
> entire list of screens (from standard means) and then start with the
> controllers they could crawl through all controller requests to the various
> presentment artifacts making note of each screen that gets hit (either
> directly or from crawling the decorators/include-screens/etc) making note
>  of each screen found.  In the end you can fail on any defined screens that
>  are not referenced anywhere in the system.
> 
> By far the most interesting thing I am working on, and the reason for this
> message, is the ability to apply behaviour from one model to the other.
> Using the current method of setting permissions, we were thinking of
> something like this.
> 
> a) In general define permissions at the service definition.
> b) Between loading the controller requests and storing them in the cache,
>  we will walk the controller requests to the service defintion; gather up
>  the permissions; and dynamically apply them to the controller request map.
>   This modified model would be cached with new "permission" objects on the
>  controller requests.
> 
> Now while this does not get you very much (failing in the controller is not
> much different than failing in the service dispatcher); it does get us to a
> point where we can apply a similar pattern when loading / caching the model
> screens.  Specifically, if you have created an xml representation of a menu
> link when you walk the presentment model and hit that link you can crawl
> over to the related controller requests.  This has been cached now with
> permissions which you could then apply to the menu link.  In short, if you
> do not have permission the menu link now is not rendered.  Again you would
> do this crawl at load/cache time and the modified object model would be
> cached, so there is no expensive visiting at render time.
> 
> Does anyone want to have a dialog about possible community interest in
>  these set of enhancements?  I am more than willing to explain things
>  further, make adjustments, packing them up, etc.  Back to the original
>  subject; I can also piece out the change that gave control requests the
>  ability to define required permissions (understanding that there is some
>  work underway to change how permissions are done).
> 

Re: Defining required permissions at the controller request

[Adrian Crum <ad...@hlmksw.com>]

My personal opinion is that most of the immutable Java classes that are 
cached in memory (the various model classes) should implement the 
visitor pattern. I have suggested it in the past, but there wasn't much 
interest in it.

-Adrian

Bob Morley wrote:
> Have been working on some integration between the various modeled objects in
> Ofbiz and came across a requirement to allow specification of required
> permissions for a controller request.  Effectively what I have been working
> on is the ability to walk various model graphs extend behaviour to one model
> from the other.  What I have working so far is some extension and clean-up
> to the presentment model, control model, and service model including the
> ability for these models to accept a visitor.
> 
> So far I have only really worked on base visitors that navigate through a
> model or crawl from one model to another model.  This has enabled us to
> write some interesting unit tests -- for example, by starting with the
> controllers I was able to crawl through every screen in the system which
> crawled the various soft links to forms, menus, trees, etc.  Failures were
> reported in the unit test; so in effect the unit test verifies that you have
> not created any bad includes.  From the source I had I only found one error
> in the set of Ofbiz screens (lots in our hot-deploy) :)
> 
> Other interesting things become possible.  For example, one could get the
> entire list of screens (from standard means) and then start with the
> controllers they could crawl through all controller requests to the various
> presentment artifacts making note of each screen that gets hit (either
> directly or from crawling the decorators/include-screens/etc) making note of
> each screen found.  In the end you can fail on any defined screens that are
> not referenced anywhere in the system.
> 
> By far the most interesting thing I am working on, and the reason for this
> message, is the ability to apply behaviour from one model to the other. 
> Using the current method of setting permissions, we were thinking of
> something like this.
> 
> a) In general define permissions at the service definition.
> b) Between loading the controller requests and storing them in the cache, we
> will walk the controller requests to the service defintion; gather up the
> permissions; and dynamically apply them to the controller request map.  This
> modified model would be cached with new "permission" objects on the
> controller requests.
> 
> Now while this does not get you very much (failing in the controller is not
> much different than failing in the service dispatcher); it does get us to a
> point where we can apply a similar pattern when loading / caching the model
> screens.  Specifically, if you have created an xml representation of a menu
> link when you walk the presentment model and hit that link you can crawl
> over to the related controller requests.  This has been cached now with
> permissions which you could then apply to the menu link.  In short, if you
> do not have permission the menu link now is not rendered.  Again you would
> do this crawl at load/cache time and the modified object model would be
> cached, so there is no expensive visiting at render time.
> 
> Does anyone want to have a dialog about possible community interest in these
> set of enhancements?  I am more than willing to explain things further, make
> adjustments, packing them up, etc.  Back to the original subject; I can also
> piece out the change that gave control requests the ability to define
> required permissions (understanding that there is some work underway to
> change how permissions are done).