Live tests are OK in GCE and Azure. I squashed the commits and amended the
commit message to reflect that the change is not particular to the
JWTBearerTokenFlow.
Merged to master as
[913fdeb1](http://git-wip-us.apache.org/repos/asf/jclouds/commit/913fdeb1).
Thanks @daniel-h-rech!
--
You are
Closed #988.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/988#event-774791065
I'll do it. Thanks! I'll run a quick the on azure and squash and merge.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/988#issuecomment-243727856
I fixed the remaining flows.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/988#issuecomment-243641639
@daniel-h-rech pushed 1 commit.
64ba963 JCLOUDS-1148 JWTBearerTokenFlow.tokenCache never hits
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@daniel-h-rech pushed 1 commit.
5e85034 JCLOUDS-1148 JWTBearerTokenFlow.tokenCache never hits
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
>ClientCredentialsJWTBearerTokenFlow actually uses ClientCredentialsClaims and
>ClientCredentialsAuthArgs.
Yes @daniel-h-rech. What I mean is that it also [uses random values to build
the object being cached](
Hey, just seeing this. Let me take a look and comment a bit later today.
-j
On Mon, Aug 8, 2016 at 4:30 PM, daniel-h-rech
wrote:
> I see no reference to ClientSecret in ClientCredentialsJWTBearerTokenFlow,
> only in ClientCredentialsSecretFlow.
>
>
I see no reference to `ClientSecret` in `ClientCredentialsJWTBearerTokenFlow`,
only in `ClientCredentialsSecretFlow`.
`ClientCredentialsSecretFlow` is actually sending the secret key every time, so
setting an expiration time seems redundant.
ClientCredentialsJWTBearerTokenFlow actually uses
The `ClientSecret` class is also used in the
`ClientCredentialsJWTBearerTokenFlow`, and the expires seems to be used there.
Instead of removing it, would it make sense to set it to null in the client
secret flow?
@jmspring WDYT?
---
You are receiving this because you are subscribed to this
It seems in `ClientCredentialsSecretFlow` we could just remove `expire()` from
`ClientSecret`, since it never really gets used.
What do you think?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks @daniel-h-rech! Change LGTM. The
[ClientCredentialsJWTBearerTokenFlow](https://github.com/jclouds/jclouds/blob/master/apis/oauth/src/main/java/org/jclouds/oauth/v2/filters/ClientCredentialsJWTBearerTokenFlow.java#L96-L111)
and the
This PR fixes
[https://issues.apache.org/jira/browse/JCLOUDS-1148](https://issues.apache.org/jira/browse/JCLOUDS-1148)
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/988
-- Commit Summary --
* JCLOUDS-1148
13 matches
Mail list logo