create/update/delete entity methods

[Chris Howe <cj...@yahoo.com>]

I'm hoping to get some feedback on creating a best
practice regarding create/update/delete entity methods
and then implementing it in JIRA.

In the project supported naming convention I'm wanting
to implement the following:

Simple method names createEntityName,
updateEntityName, and deleteEntityName should be
reserved names for the basic create, update and delete
of the entity name.  Simple enough, this is pretty
much how it's currently done, just reinforcing the
maintainance of it.

In addition, methods with createEntityName,
updateEntityName and deleteEntityName should not check
permissions.  Rather simple methods that check
permission should then call the service (or the simple
method directly if there is a performance difference).

for example, in the simple method
org/ofbiz/accounting/agreement/AgreementServices.xml#createAgreementItems
should be split into two methods.

the first being
<simple-method method-name="secureCreateAgreementItem"
description="create AgreementItem with a security
check">
<check-permission permission="ACCOUNTING"
action="_CREATE"/>
<set-service-fields to-map-name="newEntity"
service-name="createAgreementItem"
map-name="parameters"/>
<call-service service-name="createAgreementItem"
in-map-name="newEntity"/>
</simple-method>

and the second being the method that exists less the
check-permission element


This would allow for easier seperation of the data
layer from the business layer and thus an easier way
of modularizing the components. And perhaps even lead
the way to creating components programatically a la
Ruby on Ofbiz?

Re: create/update/delete entity methods

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

This is something I had suggested some time ago when I ran into problems using 
the party services. Security checks were being performed inside the Java methods 
which made it impossible for me to call them from custom code. I couldn't remove 
the security checks from the Java methods because OFBiz services assumed the 
checks were there. So I had to write duplicate Java methods with the security 
checks removed that my custom code would call.


David E Jones wrote:
> 
> Chris,
> 
> Yes, this is an interesting pattern that was half-implemented a while  
> back. I think it's fine to move security checks there, but we haven't  
> pushed this because the range of security checks supported in service  
> definitions is very limited. There are various services already that  
> have security checks too complicated to fit into what is supported  there.
> 
> Also easy customization it is a pain to have security checks there  
> because if you want something more complex you have to remove that  and 
> write something in the implementation. This is a fairly minor  issue 
> though.
> 
> In any case, I like the idea of putting more declarative security  
> checks in the service definitions themselves, but I still think it  
> would be a bad idea to write code that assumes that there is not  
> security check in the service implementation... because then if it is  
> there or if someone moves it there in customization they'll get messy/ 
> confusing problems.
> 
> -David
> 
> 
> On Oct 9, 2006, at 1:18 AM, Chris Howe wrote:
> 
>> David,
>> You said "service implementations" and it threw me
>> because all checks that I had seen were done in the
>> simple-method implementation. I just noticed an
>> implementation of security check in the service
>> definition(accounting/servicedef/services_ledger#createAcctgTrans).
>>
>> Would you be opposed to an effort to remove the
>> security checks from the methods and move the security
>> check to the service that calls the method?  This
>> would accomplish my suggestion.
>>
>> --- David E Jones <jo...@undersunconsulting.com>
>> wrote:
>>
>>>
>>> On Oct 7, 2006, at 7:43 AM, Chris Howe wrote:
>>>
>>>> In addition, methods with createEntityName,
>>>> updateEntityName and deleteEntityName should not
>>>
>>> check
>>>
>>>> permissions.  Rather simple methods that check
>>>> permission should then call the service (or the
>>>
>>> simple
>>>
>>>> method directly if there is a performance
>>>
>>> difference).
>>>
>>> This is not how it's currently done, and I really
>>> don't want to make
>>> any changes that would go in this direction. Doing
>>> this would make it
>>> very hard to approach something like centrally
>>> managed permissions.
>>> Permission and security checks should be an integral
>>> part of all
>>> service implementations.
>>>
>>> In OFBiz with the service oriented architecture,
>>> which is used as a
>>> replacement and not a supplement to an object
>>> oriented architecture
>>> on the business level, each service is responsible
>>> for its own
>>> security and I think it is important that it stay
>>> that way. I don't
>>> want to build any holes into the system...
>>> especially not as part of
>>> a best practices recommendation.
>>>
>>> -David
>>>
>>>
>>>
>>
> 
> 

Re: create/update/delete entity methods

[David E Jones <jo...@undersunconsulting.com>]

Chris,

Yes, this is an interesting pattern that was half-implemented a while  
back. I think it's fine to move security checks there, but we haven't  
pushed this because the range of security checks supported in service  
definitions is very limited. There are various services already that  
have security checks too complicated to fit into what is supported  
there.

Also easy customization it is a pain to have security checks there  
because if you want something more complex you have to remove that  
and write something in the implementation. This is a fairly minor  
issue though.

In any case, I like the idea of putting more declarative security  
checks in the service definitions themselves, but I still think it  
would be a bad idea to write code that assumes that there is not  
security check in the service implementation... because then if it is  
there or if someone moves it there in customization they'll get messy/ 
confusing problems.

-David


On Oct 9, 2006, at 1:18 AM, Chris Howe wrote:

> David,
> You said "service implementations" and it threw me
> because all checks that I had seen were done in the
> simple-method implementation. I just noticed an
> implementation of security check in the service
> definition(accounting/servicedef/services_ledger#createAcctgTrans).
>
> Would you be opposed to an effort to remove the
> security checks from the methods and move the security
> check to the service that calls the method?  This
> would accomplish my suggestion.
>
> --- David E Jones <jo...@undersunconsulting.com>
> wrote:
>
>>
>> On Oct 7, 2006, at 7:43 AM, Chris Howe wrote:
>>
>>> In addition, methods with createEntityName,
>>> updateEntityName and deleteEntityName should not
>> check
>>> permissions.  Rather simple methods that check
>>> permission should then call the service (or the
>> simple
>>> method directly if there is a performance
>> difference).
>>
>> This is not how it's currently done, and I really
>> don't want to make
>> any changes that would go in this direction. Doing
>> this would make it
>> very hard to approach something like centrally
>> managed permissions.
>> Permission and security checks should be an integral
>> part of all
>> service implementations.
>>
>> In OFBiz with the service oriented architecture,
>> which is used as a
>> replacement and not a supplement to an object
>> oriented architecture
>> on the business level, each service is responsible
>> for its own
>> security and I think it is important that it stay
>> that way. I don't
>> want to build any holes into the system...
>> especially not as part of
>> a best practices recommendation.
>>
>> -David
>>
>>
>>
>

Re: create/update/delete entity methods

[Chris Howe <cj...@yahoo.com>]

David,
You said "service implementations" and it threw me
because all checks that I had seen were done in the
simple-method implementation. I just noticed an
implementation of security check in the service
definition(accounting/servicedef/services_ledger#createAcctgTrans).

Would you be opposed to an effort to remove the
security checks from the methods and move the security
check to the service that calls the method?  This
would accomplish my suggestion.

--- David E Jones <jo...@undersunconsulting.com>
wrote:

> 
> On Oct 7, 2006, at 7:43 AM, Chris Howe wrote:
> 
> > In addition, methods with createEntityName,
> > updateEntityName and deleteEntityName should not
> check
> > permissions.  Rather simple methods that check
> > permission should then call the service (or the
> simple
> > method directly if there is a performance
> difference).
> 
> This is not how it's currently done, and I really
> don't want to make  
> any changes that would go in this direction. Doing
> this would make it  
> very hard to approach something like centrally
> managed permissions.  
> Permission and security checks should be an integral
> part of all  
> service implementations.
> 
> In OFBiz with the service oriented architecture,
> which is used as a  
> replacement and not a supplement to an object
> oriented architecture  
> on the business level, each service is responsible
> for its own  
> security and I think it is important that it stay
> that way. I don't  
> want to build any holes into the system...
> especially not as part of  
> a best practices recommendation.
> 
> -David
> 
> 
> 

Re: create/update/delete entity methods

[Chris Howe <cj...@yahoo.com>]

--- David E Jones <jo...@undersunconsulting.com>
wrote:

> 
> In OFBiz with the service oriented architecture,
> which is used as a  
> replacement and not a supplement to an object
> oriented architecture  
> on the business level, each service is responsible
> for its own  
> security and I think it is important that it stay
> that way. I don't  
> want to build any holes into the system...
> especially not as part of  
> a best practices recommendation.
> 
> -David

As long as one can make/create make/store and
make/remove, the 'security hole' is there anyway.  If
the project were to commit to what I'm suggesting, it
would allow a developer to make their custom
installment more secure as they could enforce security
permissions on create/update/delete services that are
not currently requiring permissions.

In addition, if one wanted to lax the permission
check, one would be able to do it by simply writting a
service with the same name (secureCreateEntity,
secureUpdateEntity, secureDeleteEntity) and point to
the insecure method.  This would prevent the developer
from having to rewrite the method.  IMO one should not
be forced to adopt the security structure of the
community in order to reuse it's code and that's what
this suggestion would allow.

Re: create/update/delete entity methods

[David E Jones <jo...@undersunconsulting.com>]

On Oct 7, 2006, at 7:43 AM, Chris Howe wrote:

> In addition, methods with createEntityName,
> updateEntityName and deleteEntityName should not check
> permissions.  Rather simple methods that check
> permission should then call the service (or the simple
> method directly if there is a performance difference).

This is not how it's currently done, and I really don't want to make  
any changes that would go in this direction. Doing this would make it  
very hard to approach something like centrally managed permissions.  
Permission and security checks should be an integral part of all  
service implementations.

In OFBiz with the service oriented architecture, which is used as a  
replacement and not a supplement to an object oriented architecture  
on the business level, each service is responsible for its own  
security and I think it is important that it stay that way. I don't  
want to build any holes into the system... especially not as part of  
a best practices recommendation.

-David