We may need such a feature flag so created a PR 4334 for it.
Chetan Mehrotra
On Wed, Mar 6, 2019 at 10:47 PM Rodric Rabbah wrote:
> There is a new comment on the issue related to this patch [1] which
> suggests a deployment time parameter for enabling the feature that
> restricts whisk API
There is a new comment on the issue related to this patch [1] which
suggests a deployment time parameter for enabling the feature that
restricts whisk API keys being available to all actions. I looked at the PR
and think it can be done with some changes in the controller and the tests.
We already
I have addressed all the feedback to date for this pull request:
https://github.com/apache/incubator-openwhisk/pull/4284
As a reminder, this patch adds an annotation such that its presence with an
appropriate value will cause the API key to be added to the activation
context.
The absence of the
> Existing demo apps which a new user might deploy and uses the SDK
> won't work.
Should we think about client side tooling to help? For js functions and zip
files we can scan for occurrence of require(openwhisk) for example and generate
a warning if the annotation is missing.
This can lead
This makes sense from a security POV. Given the potential for breaking user
applications[1] - we should try to document this as widely as possible. It
could probably do with a blog post.
I've opened an issue to add this to the JS SDK itself -
Thanks to all the input here and on the PR - I think we ended up somewhere
positive. Here's a summary:
1. for pre-existing actions that are already deployed, they're
grandfathered in and will continue to behave in a way where they receive
the api key on activation. This is done by detecting the
I've implemented changes to the PR
https://github.com/apache/incubator-openwhisk/pull/4284 for backward
compatibility --- such that, actions which do not have the annotation will
still get the api key injected.
The annotation is added by the controller when an action is created or
updated unless
update -a ...) or redeployed.
We already have async users today in prod.
Olivier
Rodric Rabbah wrote on 02/14/2019 10:26:08 AM:
> From: Rodric Rabbah
> To: dev@openwhisk.apache.org
> Date: 02/14/2019 10:35 AM
> Subject: Re: change the default action context to omit api key
>
&
> If we end up making a backward incompatible change, we need to stage it:
if we do it in a way that's backward compatible for existing actions, does
that alleviate the problem for composer?
-r
Composer relies on the api key to implement asynchronous and parallel
invocations.
Omitting the api key by default would imply that a new composer release is
required whenever the change is made.
If we end up making a backward incompatible change, we need to stage it:
- stage 1: fix the
> Probably the ideal would be to replace the API key with a key with an
expiry time, that can be used only within the lifespan of the action to
invoke other actions.
Yes - a short term key with specific rights (read, write or execute) would
be superior to the current approach, for sure.
-r
>
> > Probably the ideal would be to replace the API key with a key with an
> > expiry time, that can be used only within the lifespan of the action to
> > invoke other actions.
> >
> > --
> > Michele Sciabarra
> > mich...@sciabarra.com
> >
> &g
> expiry time, that can be used only within the lifespan of the action to
> invoke other actions.
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
>
> - Original message -
> From: Rodric Rabbah
> To: dev@openwhisk.apache.org
> Subject: change the default a
- Original message -
From: Rodric Rabbah
To: dev@openwhisk.apache.org
Subject: change the default action context to omit api key
Date: Wed, 13 Feb 2019 16:08:48 -0500
Hi,
I'm looking for feedback on the following issue:
https://github.com/apache/incubator-openwhisk/issues/4226
Actions
Hi Rodric,
I agree, that the key should not be passed to the action, if it is not
required.
But in my opinion, existing actions should continue to work without any
update. But I'm OK, if all newly created actions have the default, that
they don't have an API-key.
Greetings
Christian
Am Mi., 13.
Thanks for the quick initial feedback.
I've opened a PR that excludes just the API key.
https://github.com/apache/incubator-openwhisk/pull/4284
This will be a breaking change - actions that are deployed already and
which need the key will need to be updated.
I added the annotation `-a
I agree the api_key is bad, when not using e.g. OW npm within the action. +1
for using an annotation to enable this.
activation_id is required to do the right thing for logging with concurrency
enabled - but I'm also not sure what risk it is to include that? It will be in
the response header
Hi,
I'm looking for feedback on the following issue:
https://github.com/apache/incubator-openwhisk/issues/4226
Actions receives the API key in the environment even if it is not
necessary. This should not be the default behavior. With the issue I'm
proposing that we flip the default and provide
18 matches
Mail list logo
