Authentication fails with version 4.0.2

[dakky]

Describe the bug

We are getting an 401 Unauthorized when using the version 4.0.2 of the action.

As far as I analyized the problem there seems something strange:

Output of the 4.0.2 setup step:

Setup JFrog CLI
  Downloading JFrog CLI from https://releases.jfrog.io/artifactory/jfrog-cli/v2/2.56.1/jfrog-cli-linux-amd64/jfrog
  /opt/hostedtoolcache/jf/2.56.1/x64/jf config add setup-jfrog-cli-server --url https://XXX --interactive=false --overwrite=true
Run jfrog/setup-jfrog-cli@v4.0.2
  with:
    version: 2.56.1
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x6[4](https://github.com/XXX/maven-backend/actions/runs/9067734311/job/24947679824?pr=10#step:6:4)
    JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x64
    JF_URL: XXX
    JF_ACCESS_TOKEN: 
Setup JFrog CLI
  Downloading JFrog CLI from https://releases.jfrog.io/artifactory/jfrog-cli/v2/2.5.6.1/jfrog-cli-linux-amd64/jfrog
  /opt/hostedtoolcache/jf/2.56.1/x64/jf config add setup-jfrog-cli-server --url https://XXX --interactive=false --overwrite=true

The same code with the 4.0.1 action has this diff:

  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x6[4](https://github.com/XXX/maven-backend/actions/runs/9067734311/job/24947679824?pr=10#step:6:4)
    JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x64
    JF_URL: XXX
    JF_ACCESS_TOKEN: ***
[...]

/opt/hostedtoolcache/jf/2.53.2/x64/jf config add setup-jfrog-cli-server --url https://XXX --interactive=false --overwrite=true --access-token ***

There the token gets read from the secret and is passed to the jf config add-command

Current behavior

Accessing artifactory via jf commands are failing with 401 Unauthorized

Reproduction steps

action code:

      - name: Setup JFrog CLI
        uses: jfrog/setup-jfrog-cli@v4.0.1
        env:
          JF_URL: "https://artifactory.XXX.de"
          JF_ACCESS_TOKEN: ${{ secrets.ARTIFACTORY_TOKEN }}

      - name: Run any maven build which requires artifacts from artifactory
        run: |
          jf mvn-config ....

works.

v4.0.2 not

Expected behavior

mvn build is able to pull artifacts from protected artifactrory instances

Setup JFrog CLI version

whatever is installed by the action ;)

JFrog CLI version

whatever is installed by the action ;)

Workflow operating system type and version

linux

JFrog Artifactory version (if relevant)

No response

JFrog Xray version (if relevant)

No response

[yahavi]

@dakky
Thank you for using the Setup JFrog CLI.
In the sample you posted for 4.0.2, it seems the input access token is blank:

Could you double-check and make sure the token is indeed provided? You should see ***.

[dakky]

greetings ;)

I have two branches, one with version 4.0.1 and one with 4.0.2. Same repo. The artifactory token is configured as secret into this repo an referenced in both branches via JF_ACCESS_TOKEN: ${{ secrets.ARTIFACTORY_TOKEN }} (see code snipplet in the reproduce-section of the issue). So technically a misconfiguration is impossible as it is the same repo/config

[yahavi]

@dakky
There still might be a discrepancy between the workflow YML.
Do you see *** in JF_ACCESS_TOKEN?

        env:
          JF_URL: "https://artifactory.XXX.de"
          JF_ACCESS_TOKEN: *** # <- here

Could you possibly share a screenshot to assist us in analyzing it?

Thanks!

[dakky]

the diff between the PR (on which the action fails) and the main branch (where the actions works):

Output of MR with 4.0.2 change:

output of main brach (with 4.0.1 action, which works)

Code for both actions (beside the changed version of course):

      - name: Setup JFrog CLI
        uses: jfrog/setup-jfrog-cli@v4.0.1
        env:
          JF_URL: "https://XXXX"
          JF_ACCESS_TOKEN: ${{ secrets.ARTIFACTORY_TOKEN }}

[yahavi]

Thanks for the response, @dakky.

The access token stored in ${{ secrets.JF_ACCESS_TOKEN }} serves as the input for configuring the JFrog CLI Setup.

Seems like Dependabot doesn't automatically reveal secrets:

When a Dependabot event triggers a workflow, the only secrets available to the workflow are Dependabot secrets. GitHub Actions secrets are not available. Consequently, you must store any secrets that are used by a workflow triggered by Dependabot events as Dependabot secrets. For more information, see "Configuring access to private registries for Dependabot."

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#accessing-secrets

[dakky]

ah okay. Learned something new today ;) Thanks a lot and sry for the circumstances