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 <[EMAIL PROTECTED]>
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
