Hi Rodric, all, Final parameters sound nice. I think they probably solve the challenge that Dragos outlined originally. 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? Cheers Michael On 11/01/17 23:17, "Rodric Rabbah" <rod...@gmail.com> 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 <ddas...@adobe.com> 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 >parameters. > >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). > >-r > >[1] https://github.com/openwhisk/openwhisk/pull/1710
