@nebulon The way I was thinking about this working would be to leave this entirely up to the apps rather than involving box/db in this much at all. Come up with a decent abstraction for it, and offering that as part of the manifest perhaps? Something like this:
"arguments": [ "--user", "CLOUDRON_INSTALL_USER", " --password", "CLOUDRON_INSTALL_PASSWORD" ],
Use would be as follows.
On install, check for credentialSetup presence.
If it's not present, then don't do anything.
If it's present, validate it (path must be present).
If at least one canChangeAtInstallation is true, then show a workflow asking them to set up an account/password before allowing the thing to be started.
The initial value for fields is set to its
default if present (we should ideally not provide a default password, but it's just there for completeness).
If a field doesn't have
canChangeAtInstallation, then it is set to read-only.
(The same logic exists for AfterInstallation, but it's separate in my manifest suggestion, as I can imagine that some apps won't be able to allow changing either user or password easily. But this could also be done later, as a separate feature. I think the installation flow is the most important part.)
When the user enters the login information, run credentialSetup.path in the image, replacing CLOUDRON_INSTALL_USER and CLOUDRON_INSTALL_PASSWORD in any of the arguments with the user-provided information.
Treat exit code 0 as "login information was successfully set", anything else is an error (and intercept anything on stderr back to send back to the user).
This will rely on then updating apps to have a helper script to actually make this work, but it's a low priority task anyway...
... and I guess it would also mean that older box's wouldn't be able to install apps updated to use this, unless they still also defaulted to admin/changeme on the image itself, but that's not really a problem I think.