search

Azure / azure-functions-dotnet-worker

Azure Functions out-of-process .NET language worker
MIT License
429 stars 183 forks source link

Add User secrets by default in development environment #2661

Closed mattchenderson closed 1 month ago

mattchenderson commented 2 months ago

Description

The worker does not process user secrets out of the box today. This stands in contrast to the host behavior. This can be seen most easily by moving AzureWebJobsStorage to user secrets and including a blob-triggered function, binding to a Stream. Everything will work up until the point that the worker attempts to leveraged the deferred binding and use the connection itself.

We should update our defaults to follow the same behavior as exists in ASP.NET Core:

The initialized WebApplicationBuilder (builder) provides default configuration and calls AddUserSecrets when the EnvironmentName is Development

CC @bradygaster

SeanFeldman commented 2 months ago

Ideally, I'd love to eliminate local.settings.json and leverage user secrets. Not sure if it's entirely possible, but hopefully, this issue will bring it one step closer.

liliankasem commented 1 month ago

This investigation finds that the worker does not load UserSecrets by default. However, CoreTools does try to configure UserSecrets when bootstrapping the host.

The following worker extensions were tested with varying results:

The scenarios that worked with UserSecrets were all extensions where any client handling is done on the host side. And for those that failed, they all depend on the client being created on the worker side.

The reason that UserSecrets works with Queue/EH/SB extensions is because the host is the place where UserSecrets are loaded (via CoreTools), and that is also where the client connection is made for those bindings, not the worker.

Fabio and I agree that we should configure UserSecrets by default for dev environments in 2.0.

local.settings.json is out of scope for this issue and is more of a core tools requirement/change; something we will consider as we make changes to the functions cli.

jviau commented 1 month ago

Could we update samples and our templates to advise using Host.CreateDefaultBuilder()? Or we wait until we GA 2.0 and then update to advise using Host.CreateApplicationBuilder(). This will include user secrets as well as other defaults.

liliankasem commented 1 month ago

I don't think there's any issue in updating guidance/templates/samples; but I think part of making this change is to have parity with what the host does today (i.e. user secrets "enabled" by default). If that is not a huge concern, I can scrap the PR and we could open a doc updates issue instead

jviau commented 1 month ago

Parity of user secrets between worker and host would require further discussion anyways.

Is the host and worker expected to point to the same secrets or different? How does the user specify user secrets ID for the host? It is an embedded assembly attribute, do we flow this back to the host? Does the host get its own user secrets ID?

liliankasem commented 1 month ago

Parity of user secrets between worker and host would require further discussion anyways.

Is the host and worker expected to point to the same secrets or different? How does the user specify user secrets ID for the host? It is an embedded assembly attribute, do we flow this back to the host? Does the host get its own user secrets ID?

Fair point, I am going to abandon the PR and create a new issue to track doc/template/sample changes

edit: Looks like there are already issues to track template and doc updates, repurposing the issue above for sample updates