Defining required permissions at the controller request

[Bob Morley]

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).

[Wickersheimer Jeremy]

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).
>

[Adrian Crum]

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).