You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, many code samples have you entire your Azure Cosmos DB for NoSQL endpoint and credentials using an application settings file. This presents a few risks:
This reinforces that saving your credentials in plain-text is a good idea (it's not)
Customers could inadvertently check in real credentials to their forks
I recommend that we use .NET user secrets. The secrets are persisted on the user's machine and are not available in the source code as plain text credentials.
For each project you would need to:
The maintainers run dotnet user-secrets init on each original source project. It will add a non-sensitive GUID to the project. You just check in the project with the GUID so it "works" with .NET user secrets.
When it's time for the customers to add their endpoint, just tell them to run dotnet user-secrets set CosmosUri "<nosql-account-endpoint>"
For now, you can repeat the same step for keys. When they eventually migrate to Microsoft Entra authentication and RBAC, you can drop this additional step entirely
Instead of modifying the C# project file, they can just run the project as-is.
Today, many code samples have you entire your Azure Cosmos DB for NoSQL endpoint and credentials using an application settings file. This presents a few risks:
I recommend that we use .NET user secrets. The secrets are persisted on the user's machine and are not available in the source code as plain text credentials.
For each project you would need to:
dotnet user-secrets init
on each original source project. It will add a non-sensitive GUID to the project. You just check in the project with the GUID so it "works" with .NET user secrets.dotnet user-secrets set CosmosUri "<nosql-account-endpoint>"
FYI @markjbrown
The text was updated successfully, but these errors were encountered: