Getting 400 on all downloads

[FalconerTC]

Describe the bug
As of this morning, all downloads using this action are giving a 400

eg

Fetching latest release for repo RentTheRunway/<repo>
Downloading file: <tool>-linux-amd64.tar.gz to: /runner/_work/<runner>
Error: Unexpected response: 400

Curious if anyone else just started seeing this? Maybe the API changed today?

To Reproduce
Steps to reproduce the behavior:

1. Execute a download against a private repo

Expected behavior
It should successfully download the artifact

Action Environment (please complete the following information):

• OS: ubuntu (self-hosted)

Additional context
I'm running with the following

      - uses: robinraju/release-downloader@v1.2
        with:
          repository: "RentTheRunway/<repo>"
          latest: true
          fileName: "<file>-linux-amd64.tar.gz"
          token: ${{ secrets.ACCESS_TOKEN_GITHUB }}

[FalconerTC]

Sorry, this is probably an expired token

[FalconerTC]

Actually, this doesn't seem to be related to a token expiration

[lesfadv]

We are having the same issue. This has broken our CI/CD pipeline.

[FalconerTC]

Did some more digging here and opened a Github ticket to get more info from them on what changed. The problem is authentication headers being passed on redirect requests. The text that comes along with the 400 response is "Multiple auth mechanisms are not allowed; please use either query parameters or an Authorization header". The HTTP library being used by this action (typed-rest-client) strips authentication headers for some auth types but not when set as a general header, as is done in this action. I made an issue there microsoft/typed-rest-client#302.

I'm not sure if there's a flag or something that can be set here to prevent those headers from being passed along on redirect.

[smistad]

Same issue here

[robinraju]

As @FalconerTC described, this is caused by the current rest-client used in this action sending the Authorization header when following a redirect request. Looks like a change in behaviour of gh-api . It now sends a 302 and the location of the file to be downloaded.

I may be able to look into this issue later today/this weekend only. I would replace the HTTP client library if a workaround for this can't be found.

[valentjn]

Not sure if relevant or off-topic, but using Python 3's urllib.request produces the same error when trying to download a release from GitHub with an Authorization header (this breaks my GitHub Actions workflows). I'm not using the action from this repo or its REST client. Maybe GitHub needs to fix this in their API, but I'm not sure where to report this.

Related: octokit/core.js#415

[robinraju]

Hey everyone, thanks for your inputs. I just merged a fix for this issue. It runs fine now. You can check the test logs here
https://github.com/robinraju/release-downloader/runs/4419579702?check_suite_focus=true

You may try it out from the main branch as follows.

 - uses: robinraju/release-downloader@main

I'll create a new release once someone confirms if it works as expected.

[smistad]

@robinraju It works for me 👍👍 Thanks

[ndobbs]

Hey everyone, thanks for your inputs. I just merged a fix for this issue. It runs fine now. You can check the test logs here https://github.com/robinraju/release-downloader/runs/4419579702?check_suite_focus=true

You may try it out from the main branch as follows.

 - uses: robinraju/release-downloader@main

I'll create a new release once someone confirms if it works as expected.

This fixed our builds as well! Thanks a ton!

[BevanR]

Ditto. Could we get a release please, so that we don't need to use @main?

[robinraju]

Published a new release https://github.com/robinraju/release-downloader/releases/tag/v1.3

You can use the latest version with a fix for this issue.

- name: release-downloader
  uses: robinraju/release-downloader@v1.3

Closing this issue with the resolution as described above.