The docs tell us to put he appid and password in the application settings of the web service, so what purpose is the .bot file serving? It's confusing to have values in app settings of Azure, yet in my source code (.bot file) locally. It seems like all we've done is move app settings - a concept that works for web apps and v3 bots perfectly - to a new paradigm with no gain. I was never able to figure out securing this file (encrypt/decrypt) as any time i tried things became out of sync w/ what was deployed to Azure and my bot ceased to work. This is not what we should expect of a real-world deployment story for a bot on the Microsoft Bot Framework and Azure Bot Service.
Furthermore this file complicates the devops story. Instead of different environments deploying the exact same code and altering environment vars (app settings), we now have to search/replace tokens within a file. Customary procedure for something like this has always been to have "
Still in other Azure services where there may be "encrypted" configuration available, there is a "download profile" link to supply the developer w/ the necessary credentials; this would be more preferable, with there being a UI in Azure to edit the .bot file (where saving then encrypts it)
@jamestruitt Thank you for your input. I've removed the .image, and replaced it with the text.
Adding my feedback from #5275 here:
I had the same confusion as @ayako in recognizing some settings have been encrypted because the file overall was not encrypted. However, I like to have only some settings being encrypted instead the whole file. Maybe use different setting names for encrypted content. E.g. appPassword and encryptedAppPassword.
Adding feedback from #5276 here:
The concept of requiring a shared secret to open the .bot file is not conducive to team development in an enterprise. How is the secret to open the file to be shared across a development team? What about in an open-source project? Where should the source of truth for the secret be stored?
We are about a week away from merging a set of changes into master that will address these issues. You can see the coming changes by looking at the samples found in in the samples-work-in-progress branch. We've removed the reliance on .bot files and .recipe files. .bot file configuration settings are not stored in platform specific configuration files (appsettings.json for .net and .env for Node.js). recipe files and their usage by msbot clone services has been replaced by the usage of Azure ARM templates and Az CLI commands. When this branch is merged we will also be publishing update documentation to account for these changes.
Most helpful comment
We are about a week away from merging a set of changes into master that will address these issues. You can see the coming changes by looking at the samples found in in the samples-work-in-progress branch. We've removed the reliance on .bot files and .recipe files. .bot file configuration settings are not stored in platform specific configuration files (appsettings.json for .net and .env for Node.js). recipe files and their usage by msbot clone services has been replaced by the usage of Azure ARM templates and Az CLI commands. When this branch is merged we will also be publishing update documentation to account for these changes.