Chinmay,
Thank you for the details and service references with your proposal. I have
gone thru the shopping list services and below is my observation;
The inline checks uses the single permission check and return error as per
requirement. And if permission service is not available for certain cases
then developer go for inline permission checks to return error she wants.
In the service definition we have the required-permissions and
permission-service tags. Only the permission-service service will return
custom fail/error messages if user won't have permission.
I see no way to return fail/error custom message from required-permissions
>> check-permission. In addition to your proposal I would like to propose
that, the check-permission tag should also have ability to return errors.
This should work in the same way <type-validate> work with <attribute> in
the service definition.
By doing so we will be able to replace the permission services with service
calls in the service definition. And has permission with check permission.
If community agree and you (or anyone) are willing to work on it, I would
be happy to help.
Big +1 for separating the security and business logic.
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.comwww.hotwax.co
On Sat, Sep 9, 2017 at 5:06 PM, Chinmay Patidar <
[hidden email]> wrote:
> Hello Devs,
>
> Recently, I came across the CRUD operation services for ShoppingList and
> ShoppingListItem entities. The security related checks are present inline
> in these services which violate the best practice of keeping security
> implementation different from the business logic.
>
> I would like to propose creating security services for such operations and
> to call them as a permission-service from the CRUD operation
> services definition. This will also enable users to easily modify the
> security checks for their custom implementation. ill then, I would like to
> know your thoughts on this idea.
>
> Thanks,
> *Chinmay Patidar*
>