slaneyrw
commented
1 year ago Moved issue into real repo https://github.com/Azure/azure-sdk-for-net/issues/35508, so closing
Closed slaneyrw closed 1 year ago
slaneyrw
commented
1 year ago Moved issue into real repo https://github.com/Azure/azure-sdk-for-net/issues/35508, so closing
Hi Team.
When using the ServiceBus Trigger in combination with the fullyQualifiedNamespace setting, the way the DI system is configured gives us no way to control how the TokenCredential is evaluated.
This is painfully obvious when our developers are running the function app locally. It can a while before a valid credential is returned from the (hardcoded) credential chain, given some of the credentialToken sources also retry a number of times. This needs to complete before the function app is able to respond to any triggers.
With the use-case of configuring ServiceBus queues/topics with the appropriate roles for the developer's identity, we need to authenticate as the service bus transport is opened. The usual situation is that the VisualStudio or AzureCLI credential token finally gives back a token. The simple answer is to switch back to using a connection string with a SharedAccessKey but we want to remove ALL secrets from configuration, even local dev configuration.
I've looked through all of the options that the library gives me, but I keep coming back to the fact that the ServiceBusClient all appears to be created via the AzureComponentFactoryImpl object.. This ( and it's dependencies ) are internal and there are no obvious injection points.
AzureClientsGlobalOptions, which has an CredentialFactory cannot be modified, and the DefaultAzureCredential used is hardcoded.
Can you either resolve DefaultAzureCredential, or use an IOptions\<DefaultAzureCredentialOptions> somewhere. Then we can configure the choices that are used and optimise the dev inner-loop.
At the moment, we are seriously considering dropping the Function App host in favour of a normal WebHost, where we can control the runtime. HTTP Bindings are simply replaced with MVC Routes and ServiceBus Triggers replaced with MassTransit consumers. We also get the benefit of having an OpenAPI spec without resorting to 3rd party libraries.
On a related topic, you appear to be using a side-by-side dependency model to create your ServiceBus client than the one used by the Azure.Messaging.ServiceBus and it's extension methods. This means we have to configure ServiceBus twice when we also publish from a function app. I know this is probably historical, but consolidation of your DI would be nice.