client:auth is instantly loosing the authorization

[kohlthaver]

Hi,

I hope this is the correct place, I didn't find any forum in this project to ask for help.

I have some trouble with the client:auth command. I am running the prebuild .exe file in a command shell under windows. The authorization works fine if I provide user name and password. But I want to use it for automated use without triggering a mobile 2 factor auth. So I tried client:auth only with client ID and client secret. I get a "Authentication succeeded" as result. But the next command does not have auth. It just prompts:

"Error: Authorization missing or invalid. Please (re-)authenticate first by running ´sfcc-ci auth:login´ or ´sfcc-ci client:auth´ and make sure, your client has access to the instance."

What do I have to do to so that the current shell session will keep the authorization (just like when I use auth:login, which works perfectly)? I already checked the API client configuration in account manager but did not find anything which could be done there. The Default scope is like written in the documentation.

[tobiaslohr]

Hi @kohlthaver, which commands to do plan to run the automation for? If it's one of the sandbox related commands sfcc-ci sandbox:* running the auth with only the client credentials will not work today, as the sandbox API (subsequently the sandbox commands) expect an oauth grant type which includes user information. That may either be the implicit flow which is done by sfcc-ci auth:login (if the user is present) or the resource_owner_password_credentials grant if you use sfcc-ci client:auth alongside client AND user credentials. The latter may be used for automation purposes. In order manage sandboxes and to automate it is good practice to create a service user account in your org in Account Manager, grant the required role Sandbox API User and disable 2FA for this role in your org settings.

[Trimud]

Hi @tobiaslohr,

I'm following your suggestion for creating a user with Sandbox API User role. This would work for ODS (On-Demand Sandboxes) but what could we do if we want to skip 2FA for CI/CD tools with build suite? The user still needs Business Manager Administrator role for this and right now all my Github Actions using sfcc-ci client:auth are failing.

Thank you in advance

[tobiaslohr]

Hey @Trimud, does your issue still exist or where you able to solve it? Two thoughts on this:

• The Sandbox API has recently been updated and now accepts API clients be be authenticated without a user. This is required to fully run automated sandbox management without a user or a service user present. Hence, you are not running into 2FA like if a user is authenticated. To make use of this, go to your API client in Account Manager and assign it the Sandbox API User role with the respective tenant (sandbox realm).
• The CLI persists the access token obtained through sfcc-ci auth:login and sfcc-ci client:auth in a local config file. On Windows this file is located at %APPDATA%\sfcc-ci-nodejs\Config (for example, C:\Users\USERNAME\AppData\Roaming\sfcc-ci-nodejs\Config). After running the auth, please check this config file on your machine, if it has a property SFCC_CLIENT_TOKEN with a value set.

[Trimud]

Thank you Tobias, I'll give it a try in our automated sandbox management tool. This would solve a lot of issues like expiring user passwords etc.

[jenssimon]

Hi,

any news on that issue?

I'm currently trying to set up GitHub Actions to automate deployment to development instance (and later staging).

A simplified version of what I have:

  deploy_development:
    runs-on: ubuntu-latest
    env:
      SFCC_INSTANCE: {{ vars.SFCC_INSTANCE_DEVELOPMENT }}
      SFCC_OAUTH_CLIENT_ID: ${{ vars.SFCC_OAUTH_CLIENT_ID }}
      SFCC_OAUTH_CLIENT_SECRET: ${{ secrets.SFCC_OAUTH_CLIENT_SECRET }}
    steps:
    - uses: actions/checkout@v3

    # ...

    - name: Upload code
      run: |
        yarn sfcc-ci client:auth
        yarn sfcc-ci code:deploy ./dist/$SFCC_VERSION.zip -i $SFCC_INSTANCE

Running in terminal on my machine this works fine:

yarn sfcc-ci client:auth
yarn sfcc-ci code:deploy ./dist/$SFCC_VERSION.zip -i $SFCC_INSTANCE

But when running on GitHub Actions I get into the same situation as described above. It looks like the access token/SFCC_CLIENT_TOKEN got lost between the two commands.

Authentication succeeded
Error: WebDAV authentication failed. Please (re-)authenticate first by running ´sfcc-ci auth:login´ or ´sfcc-ci client:auth´. No token auto-renewal is performed. If the problem still occurs please check the WebDAV Client Permissions on the instance and ensure your client ID has been granted access to required WebDAV resources.
Error: Process completed with exit code 1.

At the moment I try to understand how SFCC_CLIENT_TOKEN is persisted between multiple commands. Since following won't result into setting an environment variable:

https://github.com/SalesforceCommerceCloud/sfcc-ci/blob/55c2f639cebd9602036ea65fc2ff5d118d1e1dd2/lib/auth.js#L332-L334

Also I think it would make perfect sense to set this as an environment variable. Or to have the access token as an output of the command.

[jenssimon]

Looks like I got this error because of missing privileges.

Missed to think about using -D.

[tobiaslohr]

@jenssimon The CLI tool still maintains configuration on disk of the machine you run it on. That includes the access token obtained as part of the auth flow.

[jenssimon]

@tobiaslohr I'm flashed 📸 by the https://github.com/sindresorhus/conf package. Haven't had a look on that yet. Looks like having fun.

My problem is solved. But it took a while till I found what I'm doing wrong.

Maybe the part of the error message easily runs out of sight:

[...] ensure your client ID has been granted access to required WebDAV resources.

Could you consider re-phrasing the whole message a bit? Or maybe line breaks could help.

[jenssimon]

💡 Idea

It could be useful to expose the access token via CLI. Currently I don't have a use case for it. But doing authentication via sfcc-ci feels right. Doing something with the result of that outside of the sfcc-ci context would make sense.

Following operations can benefit of the result of a client:auth/... call by using the resulting access token.

[tobiaslohr]

@jenssimon

Could you consider re-phrasing the whole message a bit? Or maybe line breaks could help.

Totally agree, the error message was very misleading.

It could be useful to expose the access token via CLI.

We have this already. Please take a look at sfcc-ci client:auth:token