You're raising a different issue that is orthogonal to final/immutable parameters. For sequences and parameter scoping see this discussion: https://github.com/openwhisk/openwhisk/issues/116
-r > On Jan 17, 2017, at 7:47 AM, Michael Marth <[email protected]> wrote: > > 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" <[email protected]> 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 <[email protected]> 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
