HTTP 422 messages are for validation errors, but OAUTH permissions
suggestions get printed anyways. Most times, the user probably has the
right permissions. This fix adds the check to avoid printing a confusing
message.
Co-authored-by: Mislav Marohnić <mislav@github.com>
- Supports passing a PR as argument, not just issues
- Makes it non-fatal when project cards were not able to load
- Cleans up legacy method for fetching issues
- `issue close` no longer fetches all issue fields and thus avoids the
problem when loading failed due to token not having access to projects
- `issue close` now accepts either issue or pull number as argument.
If a 4xx server response lists scopes in the X-Accepted-Oauth-Scopes
header that are not present in the X-Oauth-Scopes header, the final
error messaging on stderr will now include a hint for the user that they
might need to request the additional scope:
$ gh codespace list
error getting codespaces: HTTP 403: Must have admin rights to Repository. (https://api.github.com/user/codespaces?per_page=30)
This API operation needs the "codespace" scope. To request it, run: gh auth refresh -h github.com -s codespace
The "path" field of a GraphQL error object contains a mix of strings and
numbers and cannot be deserialized into `[]string`. Fortunately, we
don't need to rely on the "path" field and instead have the final error
message be constructed by aggregating human-readable "message" fields.
GitHub REST resources typically return full URLs to fetch related
resources at. We used to parse those URLs to find just the path portion
and pass that in to the `REST()` function, which only accepted paths. By
doing so, we are essential de-constructing a URL just to re-assemble it
again. While re-assembling it for Enterprise, though, we would
accidentally inject an extra `api/v3/` prefix where one was not needed.
The solution is just to use raw URLs as reported by the REST API with
no modifications. This extends the `REST()` function to accept full URLs
in addition to just paths to resources.
We install an HTTP middleware that adds the "Authorization" header on
every HTTP request. However, our asset download process might redirect
to a 3rd-party host (Amazon S3) and we want to allow those requests but
not require that they are authenticated.
Furthermore, we need the ability to specify the `Accept` request header
without it being overwritten by middleware, so now middleware only adds
headers that are not present in a request.
Ensure the response body is fully read and closed to reuse the same TCPconnection.
Co-authored-by: Kumar Saurabh <kumarsaurabh@Kumars-MacBook-Air.local>
`admin:org` is inclusive of `read:org`, so if we find the former listed
in response headers, we can conclude that the token has necessary scopes
instead of letting a warning notice be shown.
`fmt.Errorf` hides information and makes it hard to test for specific
conditions in returned error. Return a structured error instead.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
Our code had an unspoken assumption that only one apiClient is created
during the course of a command. Violating this assumption is fine in
almost all cases, but not when we need to do a re-auth to add a new
oauth scope to a user's token.
There is likely a more elegant solution to the problem but until then
this changes determineBaseRepo to use an existing apiClient.
How this works for people with existing OAuth tokens:
$ gh issue list -L1
Notice: additional authorization required
Press Enter to open github.com in your browser...
[auth flow in the browser...]
Authentication complete. Press Enter to continue...
Showing 1 of 132 issues in cli/cli
...
Users of Personal Access Tokens get a different notice:
Warning: gh now requires the `read:org` OAuth scope.
Visit https://github.com/settings/tokens and edit your token to enable `read:org`
or generate a new token and paste it via `gh config set -h github.com oauth_token MYTOKEN`
