This prevents the admin from editing the token previously configured.
This results in the token being saved as “**********************************” when the admin edits and saves a previously saved settings.
The value of the token is essential to make certain API calls for the settings page itself to work.
If you say that the admin can simply uninstall the app and install it again in order to modify the settings, he/she loses all other configuration data that was previously saved and will have to configure it all over again. This is not ideal.
What security risk is this trying to solve? The admin is a privileged role that needs to have access to all configured data in the app marketplace. There is no need to mask the secure iparams data at all. No other role has access to this page.
Please consider reverting this change as it fails to answer several questions regarding its usefulness. Moreover, it is a huge breaking change that cannot be introduced without a platform version upgrade. It is a departure from the way apps have been built so far. The only way out seems to be to avoid using the secure iparams feature altogether.
It is only released in the FDK for now. With feedback from developers like you, we can address all the concerns and introduce the change in the production for the new apps as well.
What we are trying to solve this update:
We found it as a miss on security enhancement for secure iparam and received some feedback from some customers that the previously stored values should not be visible across all the admin users. We wanted to address this concern with this update.
We would also like to get your feedback and see how we can address it along with this security enhancement.
Let me discuss your reported issues with the team and get back to you shortly.
Looking forward to having a discussion reagarding the issues that FDK 9.5.0 brings along with it.
Issue 1: Fail to understand why it is a security breach.
Firstly, I do not understand why it is a security concern if the configured settings are visible to the admin. Afterall, the admin is a privileged role and should have access to the stored iparams at all times for a variety of reasons including bookkeeping. The secure iparams are already not being shown to agents and lesser privileged users on the platform. Where is the security breach?
Issue 2: Challenges in app lifecycle management.
The admin installs the app providing the secret tokens.
The admin then edits the app settings. The app receives “********************” for the value of the token.
Now, when the admin saves the settings, the new value that gets stored for that secure iparam will be “********************”. This will break the app’s functionality. Proposed solution: Provide a programmatic way to fetch the secure iparams values. One way I can think of is to use server method to fetch the secure values alone. This workaround will still expose the secret iparams on network calls and will fail the reason why you brought this change in the first place. Therefore, it is better to simply not mask the secure tokens in the iparams settings page.
