Add support for dw.js file so comments and secure password storage can be used about sfcc-ci HOT 5 CLOSED

@Eneris Thanks for raising this! Is there any preference related to how you'd expect passwords (or more general secrets) to be stored? Ideally we don't want to store the secrets with the CLI itself, but rather rely on best practice methods on how to pass them into the CLI.

One option is env vars, another option (based on env vars) the .env file.

The currently supported methods to pass the secrets are via explicit command args or inside a dw.json, see auth:login and client:auth.

Adding env var and .env can be done, we would however have to follow a meaningful fallback strategy with precedence.

Something like:

• Use args explicitly passed to the command (if present)
• Use dw.json in cwd (if present)
• Use well known env vars from .env in cwd (if present)
• Use well known env vars (if present)

Feedback?

from sfcc-ci.

Hi @tobiaslohr . Sorry for the late reply.
That sounds perfect. One additional "nice to have" that I came across in last few days while implementing "one-command" sandbox prepare is, to expose functionality as module functions to enable more versatility.

Thanks :)

from sfcc-ci.

Thanks @Eneris, may I ask you to provide an example .env file (with scrubbed credentials of course)?

One additional "nice to have" that I came across in last few days while implementing "one-command" sandbox prepare is, to expose functionality as module functions to enable more versatility.

For this, can you please raise a new issue?

from sfcc-ci.

Suggestion for well-known env vars:

• SFCC_CLIENT_ID
• SFCC_CLIENT_SECRET
• SFCC_USER_NAME
• SFCC_USER_PASSWORD

Re-named proposed env vars:

• SFCC_OAUTH_CLIENT_ID
• SFCC_OAUTH_CLIENT_SECRET
• SFCC_OAUTH_USER_NAME
• SFCC_OAUTH_USER_PASSWORD

from sfcc-ci.

Any feedback on this @Eneris ?

from sfcc-ci.