There was already a per-request call to get the read or write scope. I don't think there is significant impact.
On Nov 24, 2017 9:44 PM, "Andrea Turli" <andrea.tu...@gmail.com> wrote: > Hi! > > the approach looks sensible to me, especially because it is backwards > compatible. > > Do you envisage any significant impact on the performances due to on per > request basis switch? > > I'll try to give it a try asap. > > Cheers > > On Fri, Nov 24, 2017 at 5:18 PM, Ignasi Barrera <n...@apache.org> wrote: > > > 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/5e384265ae738b913863931e89d8e3 > > 7a3170b155 > > > > And here the change to Azure ARM: > > https://github.com/nacx/jclouds-labs/commit/ > 5212be898c3100f4caf07f0dbaa071 > > f99563a6e5 > > > > 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 > > >
