Hi! I've been thinking about this and perhaps we could extend the OAuth API to allow dynamic configuration of each OAuth property. I've created a branch to play with and see if this approach could work:
Here is the change to OAuth (backwards-compatible): https://github.com/nacx/jclouds/commit/5e384265ae738b913863931e89d8e37a3170b155 And here the change to Azure ARM: https://github.com/nacx/jclouds-labs/commit/5212be898c3100f4caf07f0dbaa071f99563a6e5 The idea is to apply the same pattern we were applying tot he OAuth scopes, but provide all the configuration per-request. The default implementation just returns the values configured as context properties, but custom ones can be bound to the Guice context to provide custom values per-request. @Jim, @Andrea could you give this approach a try and see if we can use this to remove the custom keyvault filter in Azure ARM? With this approach we should be able to keep using the OAuthFilter. On 21 November 2017 at 04:34, Jim Spring <jmspr...@gmail.com> wrote: > @Ignasi/@Andrea - > > I'm guilty for writing the code as it is in OAuth, I should have thought > ahead. > > Azure KeyVault has a dynamic resource (the vault URI) that > authorization must be requested against. In the current PR, @Andrea > added the KeyVaultFilter to support this, mostly duplicating > ClientCredentialsSecretFlow. With Azure, conceivably we could use > both ClientCredentialsJWTBearerTokenFlow and > ClientCredentialsSecretFlow. > > My thought is, to isolate the changes (for now) in azurecompute-arm > and figure out a way to work around this (while not duplicating the > code as it is in the current PR). Once the PR is in, then work on > updating jclouds proper and update azurecompute-arm accordingly. > > Thoughts? > > Thanks > -jim
