We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.
For technical issues or bugs please head to Support or our Developer Community. You can assign up to 20 votes in total. Thank you for your feedback.
Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.
In the recent lights of the critical security issue reported by Optimizely regarding the package EPiServer.GoogleAnalytics, we'd like to emphasis on the importance of allowing third parties to use a Key Vault to store secrets under any DXP environments.
The impacts are otherwise major and requires any clients to rotate their shared secrets and keys completely. This would have been entirely avoided if we were able to store the secrets directly within a key vault. Even though a malicious actor would have been able to read the appsettings.json file, they couldn't have been able to retrieve the sensitive data.
As a first start, Optimizely did a great job adding the "App Settings" tab under the PaaS management portal, though unfortunately, doesn't handle simple things as supporting nested/complex configuration names (See attached). Neither there is detailed documentation on the inner working and/or why it doesn't support the same set of characters as what a Key Vault normally support for the name field. We do understand Optimizely reserves certains "prefixes" or "names" because it must not enter in conflict with the other existing configuration, but it's still unclear on how exactly the whole thing works.
There is no way to understand the purpose of the "Type" field, as there is no such concept for a configuration within ASP.NET .NET 6. The documentation also doesn't stipulate much on the subject except to say that it applies the modification for certain specific things depending on the selection. We also can't say how an Optimizely CMS/Commerce site retrieves those secrets at runtime, nor determine if it works with the Options pattern.
We would expect to be able, e.g., change the connection string MyTestDatabase, by using the following name: ConnectionStrings--MyTestDatabase. If I were to change an array of configuration, I should be able to do the following MyRootElement--MyConfigArray--0--Value.
In summary, we want the existing "App Settings" section under the PaaS portal to do the following:
Handle complex names as a key vault normally do. Examples: ConnectionStrings--MyTestDatabase or MyRootElement--MyConfigArray--0--Value.
Remove the "Type" field, it causes more confusion than resolving anything.
Explain under the documentation how partners/developers can retrieve the secret with the Options pattern. Or explain that Optimizely is using the Azure Key Vault Configuration provider out of the box, which supports the Options pattern OOB.
Thank you!
Thanks for the feedback! That would definitely improve the usability of the App Settings blade - that rule is currently there to avoid conflicts, but we could definitely solve it. I created a separate idea here https://feedback.optimizely.com/ideas/DXCS-I-431
This update is great, but you still don't allow 'EPiServer' in the name, for example 'EPiServer:Cms:Smtp:Network:Password'.
The error message has been updated to suggest that it is allowed now, but it's not.
Please provide a valid secret name. The name must be between 1 and 127 characters long. Secret names can only contain alphanumeric, double underscore, and colon characters.
We just released some changes to better accommodate App Settings for CMS 12. We've removed the "Type" field, all settings are now AppSetting, and we now also allow for colon ":" and double underscore "__". I.e., the allowed characters are now [a-zA-Z0-9:_].
We are also soon adding the option to add a setting as a secret - opting to add a secret will ensure the value of the app setting cannot viewed again in the portal.
Hi, thank you for raising this! We do agree that the points you raise would make the App Settings blade in the management portal more usable - especially in allowing the same naming conventions as .NET.
We'll investigate how we can address this.