[BUG]: Artifact download fails with permission issue
tibetiroka opened this issue · comments
What happened?
In the latest version, downloading workflow artifacts fails with a permission issue (403 forbidden). This does not occur in older versions; specifically, I tested v18.12.0, and it worked using the exact same code and token. (I checked and my token is valid and has the necessary permissions; the only change between the two scenarios is the version of octokit/rest.)
Versions
Octokit/rest v20.1.0
Relevant log output
RequestError [HttpError]: Unknown error: {}
at [...] {
status: 403,
response: {
url: '[...]',
status: 403,
headers: {
'access-control-allow-origin': '*',
'access-control-expose-headers': 'Content-Length,Content-Type,Date,Server,x-ms-request-id',
'content-length': '321',
'content-type': 'application/xml',
date: 'Sun, 07 Apr 2024 13:19:07 GMT',
server: 'Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0',
'x-ms-request-id': '0e7ac65f-001e-0077-23ee-8849b0000000'
},
data: ArrayBuffer {
[Uint8Contents]: <[...] ... 221 more bytes>,
byteLength: 321
}
},
request: {
method: 'GET',
url: '[...]',
headers: {
accept: 'application/vnd.github.v3+json',
'user-agent': 'octokit-rest.js/20.1.0 octokit-core.js/5.2.0 Cloudflare-Workers',
authorization: 'token [REDACTED]'
},
request: { hook: [Function: bound bound register], redirect: 'manual' }
}
}
Code of Conduct
- I agree to follow this project's Code of Conduct
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs
. You & others like you are the reason all of this works! So thank you & happy coding! 🚀
After some more testing, I managed to narrow the bug's introduction to between 20.0.0-beta.3
and 20.0.0-beta.4
.
We switched to using native fetch
instead of node-fetch
in v8 of @octokit/request
and the redirect
option was removed. See octokit/request.js#635
Your issue may have something to do with that.
Can you share a minimal example?
The issue can be reproduced using this repo, it's about 60 lines of code.
After removing the redirect, I can get downloadArtifact
to work from the console, but not when running via wrangler
. (Some people I talk to had trouble with having itty-router
present, but that doesn't seem to cause issues for me.)
I also experimented with accessing the backend directly, using the URL address of the request when it fails. Although it gives 403 when first accessed via downloadArtifact
, a regular, unauthenticated request made from plain JS tends to work on my machine. (It does not work when deployed in a Cloudflare Worker, however, though afaik they use a slightly different JS engine. It still gives 403 there. This was tested on a public artifact from a public repo that everyone should have access to.)
Does this mean it's a wrangler/cloudflare issue, then?