openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <>
Subject Re: Passing a context object to actions
Date Tue, 17 Jan 2017 12:47:08 GMT
Hi Rodric, all,

Final parameters sound nice. I think they probably solve the challenge that Dragos outlined
However, I am not sure if they are the ideal solution for OW in general.

Let me re-cap the issue:
* assume OW deployments where an API gateway authenticates incoming requests and sets e.g.
the userId as a header that gets forwarded to the action
* the subsequently invoked action’s code wants to read that header (userId)
* if a sequence was invoked by the request each action in the sequence must be able to read
that header (and be sure that it has not been tampered with by previous actions in the sequence)

IIUC final parameters solve this challenge provided that all involved parties (gateway deployment
and all actions in the sequence) agree on the name and semantics of that header containing
the userId. That is not a problem as long as these actions always get deployed into one particular
OW deployment. However, I think it breaks compatibility of actions when moved between different
OW deployments.
I see the downsides of changing the method signature that you mentioned, Rodric. Maybe there’s
another way? (like environment variables that can be read from the function or globally accessible
objects, etc)
Is this already solved in Bluemix?


On 11/01/17 23:17, "Rodric Rabbah" <> wrote:

>+1 to @sjfink: passing large objects inline should probably be adopted as
>an anti-pattern.
>> I'm also adding an extra thought to our thread: if we want to communicate
>a "user_id" and "app_id" to the actions, but any action can edit the
>incoming event, how would we make sure that some important fields like
>these ones can't be overwritten by other actions in a sequence and they can
>be securely passed through and trusted ?
>@ddascal <> I just opened this PR that prototypes the idea
>of "final" parameters that might be applicable. This came up in discussion
>with Steve where he suggested that any defined parameter (if it has a
>value) should be considered final. This would mean that parameters on a
>package that have a default value cannot be overridden by a binding or an
>action in the package. I implemented a variant of this [1] that applies to
>certain openwhisk actions where an action may carry a "final" annotation
>which prevents an incoming request from overriding any of its predefined
>In a more general perspective, we can give up on default parameters in
>favor of final parameters everywhere. Or a compromise where parameters may
>have defaults and may be overriden from package to binding to action but
>not from invoke time parameters (as in the pull request).
View raw message