> if we get to Lambda-based functions
No if about it, this works right now and we do this in our tests :)
ResultCollector rc = getExecution().execute(context ->
context.getResultSender().lastResult("done")
);
-Dan
On Thu, Aug 17, 2017 at 9:59 AM, Udo Kohlmeyer <ukohlme...@pivotal.io>
wrote:
> I think there might be more to this than just "Data:READ"/"Data:WRITE".
> Why would we not support something like
> /*@Authorize(hasRole("functionExecutor"))*/
> or /*@Authorize(requiresPermission("DATA:READ"))*/
>
> The next question in my mind would be, if we get to Lambda-based
> functions, how do we specify authorization credentials then? Annotations
> are great to "static" definition on services, not so great for more
> "dynamic" execution of stuff...
>
>
>
> On 8/17/17 09:29, Dan Smith wrote:
>
>> I like the annotation idea, especially considering that Jared was talking
>> about adding a @RegisterableFunction annotation as well. maybe something
>> like @ResourcePermission("Data:READ") or something like that?
>>
>> -Dan
>>
>> On Thu, Aug 17, 2017 at 8:18 AM, Michael William Dodge <mdo...@pivotal.io
>> >
>> wrote:
>>
>> What about an annotation for read-only functions or a subinterface off
>>> org.apache.geode.cache.execute.Function?
>>>
>>> Sarge
>>>
>>> On 17 Aug, 2017, at 01:42, Swapnil Bawaskar <sbawas...@pivotal.io>
>>>>
>>> wrote:
>>>
>>>> Discuss fix for GEODE-2817
>>>> <https://issues.apache.org/jira/browse/GEODE-2817>
>>>>
>>>> Currently to execute a function, you will need "data:write" permission,
>>>>
>>> but
>>>
>>>> it really depends on what the function is doing. For example, if a
>>>>
>>> function
>>>
>>>> is just reading data, the function author might want users with
>>>> DATA:READ
>>>> permissions to execute the function. The two options mentioned in the
>>>> ticket are:
>>>>
>>>> 1) externalize SecurityService so that function author can use it in the
>>>> function.execute code to check authorization.
>>>> 2) add a method to function interface to tell the framework what
>>>>
>>> permission
>>>
>>>> this function needs to execute, so that the framework will check the
>>>> permission before executing the function.
>>>>
>>>> I vote for #2 because, I think, a function author will be able to easily
>>>> discover a method on the Function interface, rather than trying to look
>>>>
>>> for
>>>
>>>> SecurityService.
>>>>
>>>> I propose that we add the following new method to Function:
>>>>
>>>> default public List<ResourcePermission> requiredPermissions() {
>>>> // default DATA:WRITE
>>>> }
>>>>
>>>> In order to preserve existing behavior, the default required permission
>>>> would be DATA:WRITE.
>>>>
>>>
>>>
>
