Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/

[David E Jones-3]

On May 3, 2009, at 10:13 AM, Andrew Zeneski wrote:

> So, the revert was warranted because only you saw fit to revert it.  
> Maybe I should start looking over your code and reverting things I  
> don't agree with. That would surely drive a this community in the  
> right direction <sarcasm>.

You may have meant this sarcastically, but it's a really good point.  
One of the things that is frustrating about a lot of stuff that  
happens in OFBiz is that no one else does review it. I really  
appreciate it when people are reviewing my code and "looking over my  
shoulder" if you will, and a lot of stuff I've messed up has been  
brought up that way (and sometimes people even hop in and fix it for  
me! it's great!).

So yes, if I ever commit something you think causes more problems than  
it solves, then by all means do revert it... and there is actually  
precedence for this and people HAVE reverted stuff that I have  
committed.

In short, yes please help out with the peer review that goes on here.  
If more committers reviewed every commit with the intent of looking  
for issues things would be a lot cleaner overall.

-David

[Shi Yusen]

Do me a favor please! Please use simple English as this is an
international community. Too many times I cannot understand long
emails. :(

If you want to discuss something complicated, please use PMC mail list.

Regards,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones-3]

On May 3, 2009, at 4:57 AM, Adrian Crum wrote:

>
> --- On Sat, 5/2/09, David E Jones <[hidden email]> wrote:
>> My personal opinion on this is that the design has only
>> subjective improvements and most of it is a big step
>> backwards (easier but less flexible, for the services versus
>> direct permission part anyway, and we decided long ago that
>> flexibility was better than ease in this case; and yes there
>> is a creative way to invoke code attached to permissions,
>> but that is a bit inflexible IMO since much permission logic
>> involved multiple permissions... it's the artifact we
>> want the code attached to not the permission itself)
>
> I've been thinking about that aspect of it. If I understand  
> correctly, here are two of the issues being addressed by the new  
> security:
>
> 1. Permission checking is being done in scripts, so a programmer is  
> required to change the permission checking logic. An ordinary  
> systems administrator with no knowledge of mini-language would not  
> be able to change how permissions are checked. The new permission  
> string is supposed to make changes to permission checking easier for  
> the non-programmer administrators.
>
> 2. Permission checking isn't consistent. Two similar branches of  
> logic will check permissions in two different ways: one will check a  
> permission string, and another will run a script. This is common in  
> the UI versus the services called by the UI. A simple "has  
> permission" check is done in the UI, and then the service invoked  
> runs a script to check permissions.
>
> I agree with you that substituting the permission service with a  
> permission string is too inflexible.
>
> One of the ideas I've been toying with is the idea of a permission  
> expression. I started writing some code for that and was going to  
> put it in Jira, but I decided to put it on the shelf until the dust  
> settles from this thread.
>
> Let's say we took Andrew's new permission string and gave it more  
> oomph - where it could contain functions and such. (The expression  
> language would be simple enough for common administrators to  
> understand.) That could eliminate many of the permission checking  
> scripts. In effect, the permission string becomes a mini-script.  
> This mini-script could be used anywhere a permission string is being  
> used now.
>
> One of the problems I have with what has been proposed so far is  
> that the permission string can be ambiguous when it comes to  
> inserting parameters. For example, "update:example:${exampleId}" -  
> what does that mean? There's no way to tell by looking at it. It  
> would be preferable to have something like "update:example +  
> relatedTo(exampleId)". That permission tells me something - it  
> requires update:example permission and the user must be related to  
> exampleId in some way.
>
> I think permission expressions would solve both of the issues above.

Part of the point (if I remember right) of putting permission logic  
into little services was to help keep it consistent when that service  
is called in multiple places, especially in the input processing  
service and the output generating screen.

If we have cases where a direct permission check is done on the screen  
and a permission service is used for the input processing service,  
then we should really change the screen to also call that same service.

I guess the real trick with all of this is to make any easy way to do  
dynamic permissions. So far we have these approaches on the table  
(sorry if I missed any others...):

1. the current recommended practice of writing a service to perform  
permission logic (service can be implemented in simple-method, java,  
groovy, etc; normally the easiest way to write and maintain (and in  
the future to create tools to help write and maintain) is a simple-
method XML snippet)

2. Andrew's new pattern of attaching a groovy script to certain  
permission strings to override the normal behavior of that string

3. Adrian's idea to create some new expression (possibly extend what  
Andrew has done) and add functions to the permission string itself  
(which might eventually have boolean logic and other things, and be a  
little expression language of its own)

Does that sound about right?

When comparing these the big question for me is what will be easiest  
for users to maintain, especially less technical users (ie non-
programmers, or I guess also programmers with little time and patience)?

In general I don't know if we'll EVER be able to come up with  
something that allows non-technical users to easily configure dynamic  
permissions to handle any possible situation. On the other hand, maybe  
we can create something that handles most common cases (including both  
functionality level and simple record level cases) and leave in  
extension points so that it is possible to create more complicated  
permission logic when needed.

In other words, however we do this we probably want some configurable  
permissions that cover most stuff, and then extension mechanisms to  
drop-down to lower level tools. That is the pattern used in pretty  
much all of the OFBiz framework tools, and it would be good to apply  
it here too.

A quick note on the extension mechanism: another pattern that has  
emerged over time is to allow programmers to create custom logic and  
put it somewhere that less-technical users can refer to. The reason  
for this is that the custom stuff becomes a sort of tool that can be  
documented and then used (but not manipulated) by less technical users  
as part of their configuration. In other words the pattern would look  
like the configuration part of things having the ability to reference  
the custom logic part of things, and not the other way around (to make  
it clear, that's a big distinction between #1 and #2 above, and I'm  
not sure about #3 since it seems to mostly be meant to internalize  
things in the permission string/expression instead of referring to  
external stuff, but could certainly easily point explicitly to  
external stuff).

Anyway, THANK YOU Adrian, this message is a breath of fresh air (part  
of why I changed the subject line :) ) and it's great to discuss  
actual issues and patterns and possible solutions.

-David

[David E Jones-3]

Which parts are you having trouble understanding? I'm sure someone  
(probably even the original author in most cases) would be happy to  
try to clarify it for you.

-David


On May 3, 2009, at 11:20 AM, Shi Yusen wrote:

> Do me a favor please! Please use simple English as this is an
> international community. Too many times I cannot understand long
> emails. :(
>
> If you want to discuss something complicated, please use PMC mail  
> list.
>
> Regards,
>
> Shi Yusen/Beijing Langhua Ltd.
>

[Andrew Zeneski-2]

Just for clarification,  my proposal did include a new way to write  
permissions using groovy, but it also supports permissions as services  
ad well as a new interface to implement very common permission  
checking routines for re-usability.

This was only one part of the proposal, the main focus is on not  
attaching the logic directly to the service instead it is attached to  
a verbose permission. The reason for this is to make customization of  
the permission logic easy to maintain, and not require modifying the  
actual application.

The point is, the groovy part you keep referring to is just a minor  
extra and not the focus of the framework.

Andrew


On May 3, 2009, at 1:38 PM, David E Jones  
<[hidden email]> wrote:

>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <[hidden email]>  
>> wrote:
>>> My personal opinion on this is that the design has only
>>> subjective improvements and most of it is a big step
>>> backwards (easier but less flexible, for the services versus
>>> direct permission part anyway, and we decided long ago that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand  
>> correctly, here are two of the issues being addressed by the new  
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is  
>> required to change the permission checking logic. An ordinary  
>> systems administrator with no knowledge of mini-language would not  
>> be able to change how permissions are checked. The new permission  
>> string is supposed to make changes to permission checking easier  
>> for the non-programmer administrators.
>>
>> 2. Permission checking isn't consistent. Two similar branches of  
>> logic will check permissions in two different ways: one will check  
>> a permission string, and another will run a script. This is common  
>> in the UI versus the services called by the UI. A simple "has  
>> permission" check is done in the UI, and then the service invoked  
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a  
>> permission string is too inflexible.
>>
>> One of the ideas I've been toying with is the idea of a permission  
>> expression. I started writing some code for that and was going to  
>> put it in Jira, but I decided to put it on the shelf until the dust  
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more  
>> oomph - where it could contain functions and such. (The expression  
>> language would be simple enough for common administrators to  
>> understand.) That could eliminate many of the permission checking  
>> scripts. In effect, the permission string becomes a mini-script.  
>> This mini-script could be used anywhere a permission string is  
>> being used now.
>>
>> One of the problems I have with what has been proposed so far is  
>> that the permission string can be ambiguous when it comes to  
>> inserting parameters. For example, "update:example:${exampleId}" -  
>> what does that mean? There's no way to tell by looking at it. It  
>> would be preferable to have something like "update:example +  
>> relatedTo(exampleId)". That permission tells me something - it  
>> requires update:example permission and the user must be related to  
>> exampleId in some way.
>>
>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic  
> into little services was to help keep it consistent when that  
> service is called in multiple places, especially in the input  
> processing service and the output generating screen.
>
> If we have cases where a direct permission check is done on the  
> screen and a permission service is used for the input processing  
> service, then we should really change the screen to also call that  
> same service.
>
> I guess the real trick with all of this is to make any easy way to  
> do dynamic permissions. So far we have these approaches on the table  
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform  
> permission logic (service can be implemented in simple-method, java,  
> groovy, etc; normally the easiest way to write and maintain (and in  
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>
> 2. Andrew's new pattern of attaching a groovy script to certain  
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what  
> Andrew has done) and add functions to the permission string itself  
> (which might eventually have boolean logic and other things, and be  
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest  
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and  
> patience)?
>
> In general I don't know if we'll EVER be able to come up with  
> something that allows non-technical users to easily configure  
> dynamic permissions to handle any possible situation. On the other  
> hand, maybe we can create something that handles most common cases  
> (including both functionality level and simple record level cases)  
> and leave in extension points so that it is possible to create more  
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some  
> configurable permissions that cover most stuff, and then extension  
> mechanisms to drop-down to lower level tools. That is the pattern  
> used in pretty much all of the OFBiz framework tools, and it would  
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has  
> emerged over time is to allow programmers to create custom logic and  
> put it somewhere that less-technical users can refer to. The reason  
> for this is that the custom stuff becomes a sort of tool that can be  
> documented and then used (but not manipulated) by less technical  
> users as part of their configuration. In other words the pattern  
> would look like the configuration part of things having the ability  
> to reference the custom logic part of things, and not the other way  
> around (to make it clear, that's a big distinction between #1 and #2  
> above, and I'm not sure about #3 since it seems to mostly be meant  
> to internalize things in the permission string/expression instead of  
> referring to external stuff, but could certainly easily point  
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air  
> (part of why I changed the subject line :) ) and it's great to  
> discuss actual issues and patterns and possible solutions.
>
> -David
>

[Anil Patel-3]

Inline.

On May 3, 2009, at 1:36 PM, David E Jones wrote:

>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <[hidden email]>  
>> wrote:
>>> My personal opinion on this is that the design has only
>>> subjective improvements and most of it is a big step
>>> backwards (easier but less flexible, for the services versus
>>> direct permission part anyway, and we decided long ago that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand  
>> correctly, here are two of the issues being addressed by the new  
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is  
>> required to change the permission checking logic. An ordinary  
>> systems administrator with no knowledge of mini-language would not  
>> be able to change how permissions are checked. The new permission  
>> string is supposed to make changes to permission checking easier  
>> for the non-programmer administrators.

I see potential in proposed system. Now we have a logical string that  
defines permission requirements. If the string points to entity then  
check permission service will do the job. In case string points to  
logical entity in system like "sfa:contact" then permission check  
service can look in auto-grant data to find dependency.
We can build tools for Administrator to add entity level permission,  
e.g  "sfa:contact" will have partymgr:party as auto-grant.

>>
>>
>> 2. Permission checking isn't consistent. Two similar branches of  
>> logic will check permissions in two different ways: one will check  
>> a permission string, and another will run a script. This is common  
>> in the UI versus the services called by the UI. A simple "has  
>> permission" check is done in the UI, and then the service invoked  
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a  
>> permission string is too inflexible.

I don't agree with inflexible part. Instead existing way of embedding  
permission rules in services are too rigid/static. I cannot query  
permission check service to find out what kind of permission is  
required. The new permission string thing lets me do that. I can query  
service model to get information on what kind of permissions are  
required to run that service. This allows me to build tools that makes  
administrator life lot easy.
The auto-grant extension make it so much flexible because its data  
driven.

>>
>>
>> One of the ideas I've been toying with is the idea of a permission  
>> expression. I started writing some code for that and was going to  
>> put it in Jira, but I decided to put it on the shelf until the dust  
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more  
>> oomph - where it could contain functions and such. (The expression  
>> language would be simple enough for common administrators to  
>> understand.) That could eliminate many of the permission checking  
>> scripts. In effect, the permission string becomes a mini-script.  
>> This mini-script could be used anywhere a permission string is  
>> being used now.
>>

Do you mean Administrator will exit servicedef file? I think its too  
much to expect from them. Also it will require redeployment.

>> One of the problems I have with what has been proposed so far is  
>> that the permission string can be ambiguous when it comes to  
>> inserting parameters. For example, "update:example:${exampleId}" -  
>> what does that mean? There's no way to tell by looking at it. It  
>> would be preferable to have something like "update:example +  
>> relatedTo(exampleId)". That permission tells me something - it  
>> requires update:example permission and the user must be related to  
>> exampleId in some way.
>>
I don't see how adding relatedTo adds meaning. Dynamic access thing  
comes into play only if we are going to check if user is related to a  
particular data.

>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic  
> into little services was to help keep it consistent when that  
> service is called in multiple places, especially in the input  
> processing service and the output generating screen.
>
> If we have cases where a direct permission check is done on the  
> screen and a permission service is used for the input processing  
> service, then we should really change the screen to also call that  
> same service.
>
> I guess the real trick with all of this is to make any easy way to  
> do dynamic permissions. So far we have these approaches on the table  
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform  
> permission logic (service can be implemented in simple-method, java,  
> groovy, etc; normally the easiest way to write and maintain (and in  
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>
> 2. Andrew's new pattern of attaching a groovy script to certain  
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what  
> Andrew has done) and add functions to the permission string itself  
> (which might eventually have boolean logic and other things, and be  
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest  
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and  
> patience)?
>
> In general I don't know if we'll EVER be able to come up with  
> something that allows non-technical users to easily configure  
> dynamic permissions to handle any possible situation. On the other  
> hand, maybe we can create something that handles most common cases  
> (including both functionality level and simple record level cases)  
> and leave in extension points so that it is possible to create more  
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some  
> configurable permissions that cover most stuff, and then extension  
> mechanisms to drop-down to lower level tools. That is the pattern  
> used in pretty much all of the OFBiz framework tools, and it would  
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has  
> emerged over time is to allow programmers to create custom logic and  
> put it somewhere that less-technical users can refer to. The reason  
> for this is that the custom stuff becomes a sort of tool that can be  
> documented and then used (but not manipulated) by less technical  
> users as part of their configuration. In other words the pattern  
> would look like the configuration part of things having the ability  
> to reference the custom logic part of things, and not the other way  
> around (to make it clear, that's a big distinction between #1 and #2  
> above, and I'm not sure about #3 since it seems to mostly be meant  
> to internalize things in the permission string/expression instead of  
> referring to external stuff, but could certainly easily point  
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air  
> (part of why I changed the subject line :) ) and it's great to  
> discuss actual issues and patterns and possible solutions.
>
> -David
>

[Anil Patel-3]

On May 3, 2009, at 2:43 PM, Anil Patel wrote:

> Inline.
>
> On May 3, 2009, at 1:36 PM, David E Jones wrote:
>
>>
>> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sat, 5/2/09, David E Jones <[hidden email]>  
>>> wrote:
>>>> My personal opinion on this is that the design has only
>>>> subjective improvements and most of it is a big step
>>>> backwards (easier but less flexible, for the services versus
>>>> direct permission part anyway, and we decided long ago that
>>>> flexibility was better than ease in this case; and yes there
>>>> is a creative way to invoke code attached to permissions,
>>>> but that is a bit inflexible IMO since much permission logic
>>>> involved multiple permissions... it's the artifact we
>>>> want the code attached to not the permission itself)
>>>
>>> I've been thinking about that aspect of it. If I understand  
>>> correctly, here are two of the issues being addressed by the new  
>>> security:
>>>
>>> 1. Permission checking is being done in scripts, so a programmer  
>>> is required to change the permission checking logic. An ordinary  
>>> systems administrator with no knowledge of mini-language would not  
>>> be able to change how permissions are checked. The new permission  
>>> string is supposed to make changes to permission checking easier  
>>> for the non-programmer administrators.
> I see potential in proposed system. Now we have a logical string  
> that defines permission requirements. If the string points to entity  
> then check permission service will do the job. In case string points  
> to logical entity in system like "sfa:contact" then permission check  
> service can look in auto-grant data to find dependency.
> We can build tools for Administrator to add entity level permission,  
> e.g  "sfa:contact" will have partymgr:party as auto-grant.
>
>>>
>>>
>>> 2. Permission checking isn't consistent. Two similar branches of  
>>> logic will check permissions in two different ways: one will check  
>>> a permission string, and another will run a script. This is common  
>>> in the UI versus the services called by the UI. A simple "has  
>>> permission" check is done in the UI, and then the service invoked  
>>> runs a script to check permissions.
>>>
>>> I agree with you that substituting the permission service with a  
>>> permission string is too inflexible.
> I don't agree with inflexible part. Instead existing way of  
> embedding permission rules in services are too rigid/static. I  
> cannot query permission check service to find out what kind of  
> permission is required. The new permission string thing lets me do  
> that. I can query service model to get information on what kind of  
> permissions are required to run that service. This allows me to  
> build tools that makes administrator life lot easy.
> The auto-grant extension make it so much flexible because its data  
> driven.
>
>>>
>>>
>>> One of the ideas I've been toying with is the idea of a permission  
>>> expression. I started writing some code for that and was going to  
>>> put it in Jira, but I decided to put it on the shelf until the  
>>> dust settles from this thread.
>>>
>>> Let's say we took Andrew's new permission string and gave it more  
>>> oomph - where it could contain functions and such. (The expression  
>>> language would be simple enough for common administrators to  
>>> understand.) That could eliminate many of the permission checking  
>>> scripts. In effect, the permission string becomes a mini-script.  
>>> This mini-script could be used anywhere a permission string is  
>>> being used now.
>>>
> Do you mean Administrator will exit servicedef file? I think its too  
> much to expect from them. Also it will require redeployment.

I mean edit.

>
>
>>> One of the problems I have with what has been proposed so far is  
>>> that the permission string can be ambiguous when it comes to  
>>> inserting parameters. For example, "update:example:${exampleId}" -  
>>> what does that mean? There's no way to tell by looking at it. It  
>>> would be preferable to have something like "update:example +  
>>> relatedTo(exampleId)". That permission tells me something - it  
>>> requires update:example permission and the user must be related to  
>>> exampleId in some way.
>>>
> I don't see how adding relatedTo adds meaning. Dynamic access thing  
> comes into play only if we are going to check if user is related to  
> a particular data.
>
>>> I think permission expressions would solve both of the issues above.
>>
>> Part of the point (if I remember right) of putting permission logic  
>> into little services was to help keep it consistent when that  
>> service is called in multiple places, especially in the input  
>> processing service and the output generating screen.
>>
>> If we have cases where a direct permission check is done on the  
>> screen and a permission service is used for the input processing  
>> service, then we should really change the screen to also call that  
>> same service.
>>
>> I guess the real trick with all of this is to make any easy way to  
>> do dynamic permissions. So far we have these approaches on the  
>> table (sorry if I missed any others...):
>>
>> 1. the current recommended practice of writing a service to perform  
>> permission logic (service can be implemented in simple-method,  
>> java, groovy, etc; normally the easiest way to write and maintain  
>> (and in the future to create tools to help write and maintain) is a  
>> simple-method XML snippet)
>>
>> 2. Andrew's new pattern of attaching a groovy script to certain  
>> permission strings to override the normal behavior of that string
>>
>> 3. Adrian's idea to create some new expression (possibly extend  
>> what Andrew has done) and add functions to the permission string  
>> itself (which might eventually have boolean logic and other things,  
>> and be a little expression language of its own)
>>
>> Does that sound about right?
>>
>> When comparing these the big question for me is what will be  
>> easiest for users to maintain, especially less technical users (ie  
>> non-programmers, or I guess also programmers with little time and  
>> patience)?
>>
>> In general I don't know if we'll EVER be able to come up with  
>> something that allows non-technical users to easily configure  
>> dynamic permissions to handle any possible situation. On the other  
>> hand, maybe we can create something that handles most common cases  
>> (including both functionality level and simple record level cases)  
>> and leave in extension points so that it is possible to create more  
>> complicated permission logic when needed.
>>
>> In other words, however we do this we probably want some  
>> configurable permissions that cover most stuff, and then extension  
>> mechanisms to drop-down to lower level tools. That is the pattern  
>> used in pretty much all of the OFBiz framework tools, and it would  
>> be good to apply it here too.
>>
>> A quick note on the extension mechanism: another pattern that has  
>> emerged over time is to allow programmers to create custom logic  
>> and put it somewhere that less-technical users can refer to. The  
>> reason for this is that the custom stuff becomes a sort of tool  
>> that can be documented and then used (but not manipulated) by less  
>> technical users as part of their configuration. In other words the  
>> pattern would look like the configuration part of things having the  
>> ability to reference the custom logic part of things, and not the  
>> other way around (to make it clear, that's a big distinction  
>> between #1 and #2 above, and I'm not sure about #3 since it seems  
>> to mostly be meant to internalize things in the permission string/
>> expression instead of referring to external stuff, but could  
>> certainly easily point explicitly to external stuff).
>>
>> Anyway, THANK YOU Adrian, this message is a breath of fresh air  
>> (part of why I changed the subject line :) ) and it's great to  
>> discuss actual issues and patterns and possible solutions.
>>
>> -David
>>
>

[Anil Patel-3]

On May 3, 2009, at 1:36 PM, David E Jones wrote:

>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <[hidden email]>  
>> wrote:
>>> My personal opinion on this is that the design has only
>>> subjective improvements and most of it is a big step
>>> backwards (easier but less flexible, for the services versus
>>> direct permission part anyway, and we decided long ago that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand  
>> correctly, here are two of the issues being addressed by the new  
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is  
>> required to change the permission checking logic. An ordinary  
>> systems administrator with no knowledge of mini-language would not  
>> be able to change how permissions are checked. The new permission  
>> string is supposed to make changes to permission checking easier  
>> for the non-programmer administrators.
>>
>> 2. Permission checking isn't consistent. Two similar branches of  
>> logic will check permissions in two different ways: one will check  
>> a permission string, and another will run a script. This is common  
>> in the UI versus the services called by the UI. A simple "has  
>> permission" check is done in the UI, and then the service invoked  
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a  
>> permission string is too inflexible.
>>
>> One of the ideas I've been toying with is the idea of a permission  
>> expression. I started writing some code for that and was going to  
>> put it in Jira, but I decided to put it on the shelf until the dust  
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more  
>> oomph - where it could contain functions and such. (The expression  
>> language would be simple enough for common administrators to  
>> understand.) That could eliminate many of the permission checking  
>> scripts. In effect, the permission string becomes a mini-script.  
>> This mini-script could be used anywhere a permission string is  
>> being used now.
>>
>> One of the problems I have with what has been proposed so far is  
>> that the permission string can be ambiguous when it comes to  
>> inserting parameters. For example, "update:example:${exampleId}" -  
>> what does that mean? There's no way to tell by looking at it. It  
>> would be preferable to have something like "update:example +  
>> relatedTo(exampleId)". That permission tells me something - it  
>> requires update:example permission and the user must be related to  
>> exampleId in some way.
>>
>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic  
> into little services was to help keep it consistent when that  
> service is called in multiple places, especially in the input  
> processing service and the output generating screen.

How is writing "acctgInvoicePermissionCheck" different from  
"update:acctmgr:invoice". I cannot interpret anything out of  
acctgInvoicePermissionCheck but string does tell me something which  
goes in line with convention over configurations practice.
>
>
> If we have cases where a direct permission check is done on the  
> screen and a permission service is used for the input processing  
> service, then we should really change the screen to also call that  
> same service.
Forms and screens don't always work on data from one entity. I can use  
string to check "update:ecommerce:billingAndShippingAddress" and use  
auto-grant to power permission check service. If data for auto-grant  
is set right we will not have to write any custom code to check  
permission for most cases.

>
>
> I guess the real trick with all of this is to make any easy way to  
> do dynamic permissions. So far we have these approaches on the table  
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform  
> permission logic (service can be implemented in simple-method, java,  
> groovy, etc; normally the easiest way to write and maintain (and in  
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>

Too many rules embedded in services is bad. They make administrators  
life difficult. I have to find and read permission check service to  
figure out what permissions should be given to user.

> 2. Andrew's new pattern of attaching a groovy script to certain  
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what  
> Andrew has done) and add functions to the permission string itself  
> (which might eventually have boolean logic and other things, and be  
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest  
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and  
> patience)?

Something that does not require me to look at code and redeploy  
application.

>
>
> In general I don't know if we'll EVER be able to come up with  
> something that allows non-technical users to easily configure  
> dynamic permissions to handle any possible situation. On the other  
> hand, maybe we can create something that handles most common cases  
> (including both functionality level and simple record level cases)  
> and leave in extension points so that it is possible to create more  
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some  
> configurable permissions that cover most stuff, and then extension  
> mechanisms to drop-down to lower level tools. That is the pattern  
> used in pretty much all of the OFBiz framework tools, and it would  
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has  
> emerged over time is to allow programmers to create custom logic and  
> put it somewhere that less-technical users can refer to. The reason  
> for this is that the custom stuff becomes a sort of tool that can be  
> documented and then used (but not manipulated) by less technical  
> users as part of their configuration. In other words the pattern  
> would look like the configuration part of things having the ability  
> to reference the custom logic part of things, and not the other way  
> around (to make it clear, that's a big distinction between #1 and #2  
> above, and I'm not sure about #3 since it seems to mostly be meant  
> to internalize things in the permission string/expression instead of  
> referring to external stuff, but could certainly easily point  
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air  
> (part of why I changed the subject line :) ) and it's great to  
> discuss actual issues and patterns and possible solutions.
>
> -David
>

[Adam Heath-2]

David E Jones wrote:

> It looks like what I was afraid of is EXACTLY what happened. Andrew and
> various others seem simply not interested in feedback being convinced of
> what they have presented and not wanted to admit any appearance of
> fault, which appreciating and using feedback naturally does. If you
> think that's harsh then bash me like you've bashed Adrian. Don't
> worry... go for it! I happen to have a button with the letters "delete"
> on it, and I've been using it more and more lately.

(responding to just this paragraph, not that it really matters)

Well, *I* have a key with *Delete* on it; does that make me more
important?  Let's discuss the merits of "delete" versus "Delete", and
I'll commit 20 classes with 4200 lines in 3.7 hours to change this on
everyone's keyboard.

But, actually, yeah, for something as low-level critical as security,
anything less than a week of discussion is completely right out.  If
it is going to affect *all* code *everywhere*, then you have to allow
for *everyone* to have time to comment on it.  Not everyone is paid to
work directly on ofbiz; some do it in their spare time.  This means at
least 2 weekends of waiting.  Sometimes, even a month, so you can get
all the various eyes on it.  This is something I learned in my long
association with Debian.

[Adam Heath-2]

Andrew Zeneski wrote:
> I must admit this is very disappointing, and not a very "community" sort
> of thing I would expect from someone who is an advocate for a
> "community". Instead, this is a very tyrannical approach to the whole
> thing and very disrespectful. So far the two people who have not seen
> this being a great improvement is you and then once you spoke up Adrian
> followed.

A community has guidelines and procedures to follow.  A *worldwide*
community has even more.  There are long timelines that need to be
followed, before large-scale things can be done.  A week of time is
*not* long enough.  People need to have time to read and comprehend.

Quite often, you'll get a bunch of people immediately reading some new
proposed plan, in the first few days.  But then it'll take a week or
two before they really start to understand what it is all about.
Consider how long you thought about this.  I'm not talking about when
 you actually sat down, and said, well, today is the day I'm really
going to do this.  I'm talking about all the years you've had some
sort of thought in the back of your head about what you want to do.

> So, the revert was warranted because only you saw fit to revert it.
> Maybe I should start looking over your code and reverting things I don't
> agree with. That would surely drive a this community in the right
> direction <sarcasm>.
>
> Let's look at the current tally:
>
> Anil, Scott and I have voiced approval for this proposal.
> You and Adrian have voiced disapproval.
>
> How does 3:2 justify a automatic revert? I think what you have done
> right here was very anti-community and EXTREMELY disrespectful to the
> one person who has been working with you 8 years to bring this project
> to where it is today. So, if your goal in reverting this was to piss me
> off and ruin what little respect I have left for you, it worked.

I haven't actually looked at the new security stuff, nor at the stuff
done to example.  If the stuff you have done does *not* modify any
existing code(both security support classes, or examples, but you can
add extra helper methods), then I see no reason to do a revert.  I
don't know if that's the case here.

However, I do think that David reverted a bit too early.  He did *not*
give any warning, and just did it, and yes, that is a bit tyrannical.
 If this really is a community, then it needs to be community *all the
time*.

Have you considered doing a git or mercurial branch of all these changes?

> I will personally revert the rest of the code over the next week.

Please don't go that far.

For instance, here's one thing that you and I have already discussed.
 You added an AbstractResolver class, which scanned the classpath, and
loaded *every single org.ofbiz class*, just so you could find any
class that happened to implement an interface or extend a base class.
 I then changed that code without telling you, to use the more
efficient javax.imageio.spi.ServiceRegistry(java 1.5, in java 1.6
there is java.util.ServiceLoader).  So, here are the issues with this
particular exchange.

One, the code you wrote was not available for public discussion
*ahead* of time.  If so, I would have commented about it(given some
time, more than what was allowed), and the revision history may have
been cleaner, by not having this class.

Two, I should have asked/told you about it before doing it.  However,
I didn't know that there was some bold plan with this particular
class, and just thought it was something that had already existing in
ofbiz for a few weeks.  I wasn't aware that this was part of some new,
long-term change.  Maybe that was because I didn't see any singleton
message about it, nor any large thread about it, *before* I changed
anything.

The main reason I got back involved with OfBiz this time around was to
start upgrading the ofbiz code base to java 1.5 features, namely
generics, for-loops, auto-boxing, and other api usage; while doing so,
I've also done code walk-throughs, to find other various anti-patterns
or code duplication.  I considered this particular change just another
one of those.

[Adam Heath-2]

Don't need to actually respond to any particular thing David said,
just reusing his change of subject for my email.

==
PermissionNameOrPattern Command Action Roles
----------------------- ------- ------ -----
/Path/To/Resource UPDATE ALLOW \
        (FOO_ADMIN|FOO_UPDATE)&FOO_TRAINED
/Path/Pattern.* CREATE ALLOW \
        (FOO_ADMIN|FOO_CREATE)&FOO_TRAINED
PARTY_MGR READ ALLOW \
        PARTY_ADMIN&PARTY_TRAINED
==

We have something similiar to this in our client apps.  It hasn't yet
made it to the base webslinger code.  It's not any kind of fancy
parser.  Just tab separated(for now, that would have to change if the
Name allowed spaces).

The 'framework' is the parser, and the api that can be called by
code($resource.userAllowed($user, $command)).  The
Command/Action/Roles are not hard-coded.

Again, I haven't actually read the proposal.  The above makes the
application code easy to understand.  It's not polluted with
boiler-plate security code; instead, it has a simple string that can
be descriptive of what it is checking.  It allows clients to change
the security(based on whatever policy they have), without having to
understand any kind of programming logic.

I'm fairly good with javacc.  The above would be *simple* to write a
javacc parser for.  I've got a SQL parser sitting in the wings, as is
what I was actually working on this weekend, trying to add it to ofbiz.

[Adam Heath-2]

Anil Patel wrote:
>> Part of the point (if I remember right) of putting permission logic
>> into little services was to help keep it consistent when that service
>> is called in multiple places, especially in the input processing
>> service and the output generating screen.
> How is writing "acctgInvoicePermissionCheck" different from
> "update:acctmgr:invoice". I cannot interpret anything out of
> acctgInvoicePermissionCheck but string does tell me something which goes
> in line with convention over configurations practice.

acctmgr:invoice:update would be better, imho.  But I can see it argued
both ways.

[Andrew Zeneski-2]

Inline...

>
> Please don't revert the rest of the code. The point is that this  
> needs time to mature, so it should stay in there but not become the  
> default... not YET anyway.

I will leave the what was implemented alone for the time being.

>
> Also, please don't be personally offended by this. Just because  
> there are comments and feedback doesn't mean something has no merit,  
> it just means that some adjustments to it might be able to improve  
> it. That's what collaboration is all about, and I guess if you'd  
> rather not do it than have other people comments on it and make  
> changes to it then collaboration will be difficult.

I am not offended by any comments or feedback, I was only offended by  
your actions. Reverting the example was nothing more than a power move  
by you. You can argue this if you wish, but the fact is nothing else  
except for an example was effected, and there has been no discussion  
by anyone to revert anything yet. If you did feel that it was  
problematic, it should have been brought up if not to the community  
then at least to me personally.

>
> Just to clear that up... are you saying you would rather not do any  
> of this than make some changes and refinements to it based on  
> feedback? I hope that's not the case. My intent with this, as I  
> explained in my email, is to make a compromise and allow development  
> and improvement on this to continue without impact on other parts of  
> the project until it is more ready for that.

Your assumptions (as assumptions often are) completely wrong. Even  
though say now you hope this isn't the case, you have publicly accused  
me of this in your Notes On Security Changes document. What have I  
been doing for the past week? It surely wasn't moving ahead and  
checking in changes to all the applications to use a new authorization  
pattern. What I have been doing is acquiring additional needs/
requirements comparing them to what I have planned and trying to  
discuss with the community these changes. Refining the API and  
including the requirements which I have gathered.

You keep claiming that this new pattern is less flexible. While that  
may (but I don't agree) be true to a certain extent, is it also far  
MORE flexible when it comes to creating custom implementations for  
vertical, custom or customized applications.

Andrew

[Adam Heath-2]

Adam Heath wrote:
> Have you considered doing a git or mercurial branch of all these changes?

hg clone http://hg.webslinger.org/hg/ofbiz.apache.org/

I have that machine subscribed to the commits mailing list, and it is
automatically updated whenever a commit is done to subversion.  It
even has all the subversion branches too.  You just can't push back to it.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> David E Jones wrote:
>
>> It looks like what I was afraid of is EXACTLY what happened. Andrew and
>> various others seem simply not interested in feedback being convinced of
>> what they have presented and not wanted to admit any appearance of
>> fault, which appreciating and using feedback naturally does. If you
>> think that's harsh then bash me like you've bashed Adrian. Don't
>> worry... go for it! I happen to have a button with the letters "delete"
>> on it, and I've been using it more and more lately.
>
> (responding to just this paragraph, not that it really matters)
>
> Well, *I* have a key with *Delete* on it; does that make me more
> important?  Let's discuss the merits of "delete" versus "Delete", and
> I'll commit 20 classes with 4200 lines in 3.7 hours to change this on
> everyone's keyboard.

Mmm... mine is "Suppr" :D

Jacques

[Adrian Crum-2]

Mine has salsa splattered on it - I don't know what it says.

-Adrian


--- On Sun, 5/3/09, Jacques Le Roux <[hidden email]> wrote:

> From: Jacques Le Roux <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> Date: Sunday, May 3, 2009, 1:18 PM
> From: "Adam Heath" <[hidden email]>
> > David E Jones wrote:
> >
> >> It looks like what I was afraid of is EXACTLY what
> happened. Andrew and
> >> various others seem simply not interested in
> feedback being convinced of
> >> what they have presented and not wanted to admit
> any appearance of
> >> fault, which appreciating and using feedback
> naturally does. If you
> >> think that's harsh then bash me like
> you've bashed Adrian. Don't
> >> worry... go for it! I happen to have a button with
> the letters "delete"
> >> on it, and I've been using it more and more
> lately.
> >
> > (responding to just this paragraph, not that it really
> matters)
> >
> > Well, *I* have a key with *Delete* on it; does that
> make me more
> > important?  Let's discuss the merits of
> "delete" versus "Delete", and
> > I'll commit 20 classes with 4200 lines in 3.7
> hours to change this on
> > everyone's keyboard.
>
> Mmm... mine is "Suppr" :D
>
> Jacques

     

[Andrew Zeneski-2]

What you are describing here is very similar to the process-based  
authorization system which I proposed, the main differences is in my  
proposal everything is defined in a process [permission] string where  
this is based on artifacts. I think I need to understand this more, as  
I don't really see yet how it would work.

You mention there is no permission-checking code, but you also mention  
that if the user has a specific permission then the screen is  
displayed. This is the confusing part to me right now. How does the  
"domain" know if a user has permission if there is no permission  
checking code?

How does is the access control logic handled in this system? Could you  
explain how to accomplish this example using this pattern:

Display a list of example records, for the records the user can update  
display the update button, for the records the user can delete show  
the delete button. For the records which the user does not have these  
permissions don't display the button.

When delete is pressed, we need to make sure the user really does have  
access to delete this record, how can we verify this?

My followup question will be, how do I customize the access logic for  
a specific client so that I can maintain my own logic in a private  
component and avoid problems when updating applications?

For me these are the most important requirements (very granular  
control and ease of customizing without modifying files in the  
application).

Andrew

On May 3, 2009, at 12:57 PM, Adrian Crum wrote:

>
> Take your comment - "it's the artifact we want the code attached to  
> not the permission itself" - and combine that with Scott's  
> suggestion to have a security-aware delegator, and you have a  
> solution I proposed years ago: a domain-driven security system.
>
> In a domain-driven security system, each OFBiz artifact is  
> responsible for handling security for itself. There is no explicit  
> permission-checking code. Each OFBiz artifact identifies itself in a  
> security domain. When a user tries to use that artifact, it checks  
> the user's permissions against its own position in the domain.
>
> Using the Example component's EditExample screen as an example, here  
> is what a security domain might look like:
>
> framework
>  example
>    screen
>      EditExample (screen)
>        EditExample (form)
>
> Permissions are hierarchical - each artifact inherits permissions  
> from the artifact above it. This is very similar to what Andrew is  
> trying to achieve, but it's different because the artifacts  
> themselves control the security - there is no call to a permission  
> service with a permission string.
>
> Here's what it might look like in ExampleScreens.xml:
>
> <screens xmlns:xsi="...">
>  <security domain="framework:example:screen"/>
>
>  <screen name="EditExample">
>    <security domain="EditExample"/>
>    ...
>  </screen>
>
> </screens>
>
> Notice there are no explicit permission checks. Instead, each  
> artifact has identified itself in the security domain.
>
> When the widget is run, each artifact checks the user's permissions  
> against its own security domain. So, the EditExample screen would  
> look for the framework:example:screen:EditExample" permissions and  
> handle itself accordingly. (Andrew - this is why I suggested having  
> permission checking code return all permissions for a context.)
>
> If a user has the access:framework:example:screen:EditExample  
> permission, the screen will display.
>
> Let's take a look at what happens in the form widget. Here is what  
> ExampleForms would look like:
>
> <form name="EditExample" type="single" target="updateExample"  
> title="" default-map-name="example">
>  <security domain="EditExample"/>
>  ...
> </form>
>
> Again, when the widget is run, each artifact checks the user's  
> permissions against its own security domain. So, the EditExample  
> form would look for the  
> framework:example:screen:EditExample:EditExample" permissions and  
> handle itself accordingly.
>
> Let's say the user doesn't have any permissions for that context.  
> Keep in mind permissions are hierarchical - so the form widget would  
> work its way up the hierarchy to find permissions. If a user has the  
> access:framework:example:screen:EditExample permission, the form  
> will display plain text with no input fields. If the user has the  
> update:framework:example:screen:EditExample permission, the form  
> will provide input fields.
>
> Form fields could identify themselves in the security domain as well  
> - so only the fields the user is permitted to access will appear.
>
> Service definitions and entities could identify themselves in the  
> security domain in a similar way, and have similar permissions  
> checking logic. Some examples:
>
> framework
>  example
>    service
>      updateExample
>
> framework
>  example
>    entity
>      Example
>
> The nice thing about this approach is that you could leverage the  
> artifact gathering code to display the security domain as a tree -  
> with permission checkboxes next to each "leaf." That would enable  
> any administrator to manage user security easily.
>
> -Adrian
>
>
>
>

[Adrian Crum-2]

--- On Sun, 5/3/09, Andrew Zeneski <[hidden email]> wrote:

> What you are describing here is very similar to the
> process-based authorization system which I proposed, the
> main differences is in my proposal everything is defined in
> a process [permission] string where this is based on
> artifacts. I think I need to understand this more, as I
> don't really see yet how it would work.
>
> You mention there is no permission-checking code, but you
> also mention that if the user has a specific permission then
> the screen is displayed. This is the confusing part to me
> right now. How does the "domain" know if a user
> has permission if there is no permission checking code?

I could have been more detailed in my description, so I apologize for the confusion. As far as implementation details are concerned, I intentionally left those out. The idea is to come up with a design for security first. Once that design is finalized, we can start working on implementation.

The security domain is just a representation of how OFBiz artifacts are laid out. It's like a picture of a car. You can't drive the picture, but you can drive the car.

Each artifact registers itself in the domain. I gave an example using a <security> element. Following the picture analogy, each <security> element adds something to the picture.

When a user attempts to access the artifact, the artifact takes its location in the security domain, and the user login (or whatever) and passes that information to an authentication mechanism. The authentication mechanism returns a set of permissions (create, update, delete, view, etc). The artifact takes those permissions and uses them accordingly (display a screen or return a permission error, display form data as text, or display form data as input fields).

To continue with the picture analogy, when the user enters the picture there will be artifacts there he/she can interact with. Let's say the picture includes a car, a boat, and lawn mower. The user's ability to start the engine on the car, boat, or lawn mower depends upon their "start engine" permission for each. In other words, the car says to the authentication mechanism, "I am a car. Give me the car permissions for user Adrian." The authentication mechanism returns a list of permissions. If one of those permissions is "start engine" I am able to start the car.

> Display a list of example records, for the records the user
> can update display the update button, for the records the
> user can delete show the delete button. For the records
> which the user does not have these permissions don't
> display the button.

Entities are no different than any other OFBiz artifact - they register themselves in the security domain. Entities could extend the <security> element with additional elements and attributes that define user permission on each record.

> When delete is pressed, we need to make sure the user
> really does have access to delete this record, how can we
> verify this?

The Delete button would know to appear only when the user has delete permission. If the permission doesn't exist, then the button doesn't appear.

> My followup question will be, how do I customize the access
> logic for a specific client so that I can maintain my own
> logic in a private component and avoid problems when
> updating applications?

Why would you want to do that? I can't think of a reason why a security system would need to be changed.

> For me these are the most important requirements (very
> granular control and ease of customizing without modifying
> files in the application).

I'm confident it will meet most security needs. The concept is not mine - it's modeled after Novell Netware's security (probably Windows too). I have yet to find a limitation in the ability to control user access to network resources.

-Adrian



     

[Andrew Zeneski-2]

Because no matter how we design security for the default  
implementation in OFBiz there will always be some industry, or  
business requirement that is not covered, there is no way we can plan  
for every possible scenario. Thus, we need to make sure there are  
simple ways to modify the default behavior without having to intrude  
into the low level functionality. This is one of the key issues I have  
been trying to solve.

On May 3, 2009, at 7:26 PM, Adrian Crum wrote:

>>
>> My followup question will be, how do I customize the access
>> logic for a specific client so that I can maintain my own
>> logic in a private component and avoid problems when
>> updating applications?
>
> Why would you want to do that? I can't think of a reason why a  
> security system would need to be changed.

[Adrian Crum-2]

Understood.

If there is any interest in the design, and we start to flesh it out, I'm sure those scenarios could be presented and addressed.

-Adrian


--- On Sun, 5/3/09, Andrew Zeneski <[hidden email]> wrote:

> From: Andrew Zeneski <[hidden email]>
> Subject: Re: Domain Based Security ( was re: Authz...)
> To: [hidden email]
> Date: Sunday, May 3, 2009, 7:11 PM
> Because no matter how we design security for the default
> implementation in OFBiz there will always be some industry,
> or business requirement that is not covered, there is no way
> we can plan for every possible scenario. Thus, we need to
> make sure there are simple ways to modify the default
> behavior without having to intrude into the low level
> functionality. This is one of the key issues I have been
> trying to solve.
>
> On May 3, 2009, at 7:26 PM, Adrian Crum wrote:
>
> >>
> >> My followup question will be, how do I customize
> the access
> >> logic for a specific client so that I can maintain
> my own
> >> logic in a private component and avoid problems
> when
> >> updating applications?
> >
> > Why would you want to do that? I can't think of a
> reason why a security system would need to be changed.