Closed johnsmyth closed 1 year ago
Hi John,
I created a new token with the exact permissions outlined above, but wasn't able to replicate this issue with data I have access to.
I added new token to ~/.steampipe/config/github.spc
as gh_ro
(below censored for obvious reasons).
connection "gh_ro" {
plugin = "github"
token = "ghp_ZK[...]Hfw"
}
Quick test shows it working:
I imagine the error for you stems from the column outside_collaborators_total_count
as this nests the collaborators(affiliation: OUTSIDE) { totalCount }
into the GraphQL request.
Although, worth noting on repositories where I only have member
access it seems to return 0
where I'd expect a different value (based on what I can see in the WebUI) rather than giving me a permissions issue or anything.
The GraphQL documentation doesn't outline details about required permissions for calling certain resources, however in the REST documentation it says that to query collaborators you need read:org
and repo
permissions on your token, which is the case and I can't imagine this being much different for the GraphQL variant.
@johnsmyth - did you keep the logs for this invocation & do they highlight any extra information about the error? Maybe if we can figure out which of the repos you're associated with is causing the issue we may be able to identify a root cause.
Unfortunately, the GraphQL works a bit different in it's method of handling permission errors where in the REST SDK you sometimes just got null
when you couldn't see some data and the rest of the data was returned in the GraphQL variant you don't get back any data merely the error object.
In the meantime, I've considered how we could remediate this if it is a wider issue:
Note: This column is currently used for one control in the Sherlock mod
control.private_repo_no_outside_collaborators
Simply removing the column would break the Sherlock mod, however we currently have a github_repository_collaborator
table which returns all collaborators as the data returned even from edge doesn't contain the actual affiliation, however the GraphQL endpoint does allow for filtering by the following affiliations ALL
(default & current), DIRECT
, OUTSIDE
. Honestly I think this filtering should've been in when we added the table just missed on oversight of the affiliation not being returned in the response data I guess.
This means we could either add an optional KeyQual to this existing table (defaulted to ALL
if not set) allowing for passing the other options to filter the list as required. It would also make sense to ignore permission errors on this table to return nil, nil
as it requires a join from a repo table.
@cbruno10 - thoughts?
Took liberty of creating a branch and applying proposed changes
The plugin logs, even at trace level, dont really provide any more detail. This works fine for me in v0.27 though - I can do select * from github_my_repository
without error, and in fact i see data in some rows for both the collaborators
and outside_collaborators
columns. Perhaps the are some rows that are null because I dont have access to them - not sure - but either way i dont get any errors.
@graza-io Using your new branch, i can do select * from github_my_repository
without error, even WITHOUT specifying a filter
@johnsmyth - thanks for the additional notes on the log data.
To clarify, one key aspect of the v0.27
(api v3) -> v0.28
(api v4) change was that the collaborators data was moved to it's own table github_repository_collaborator
due to them being nested pageable resources in v4.
I figured it would be useful in general but also for the Sherlock
mod which had a control checking for outside collaborators to include a convenience field on the github_repository
and github_my_repository
tables the column populated was outside_collaborators_total_count
and its data was part of the main list for the table. I believe this is the data that is giving you a permission error in plugin version v0.28
(however, I've not been able to replicate this permission error - hence wondering if the logs would provide any helpful info into tracking down a circumstance that causes it).
In the new branch I've enhanced the github_repository_collaborator
table by adding a filter that will allow you to only obtain outside
collaborators (previously this filtering wasn't there due to oversight in that the returned data doesn't include an affiliation). I also have added a specific error catch on the error you were receiving to return nothing instead of an error as it makes more sense that in event of not having permissions you just don't get results rather than not being able to process the entire query.
I also removed the convenience field outside_collaborators_total_count
from the github_repository
and github_my_repository
tables - which based on your response clarifies that this was the issue, albeit no closer to pinning down why you wouldn't have permissions to obtain collaborators when you seemingly have the required permissions on your token.
@graza-io I suspect that the token has the required scope, but perhaps I do not have access to the field for some specific repos?
@johnsmyth - I've added another commit to the branch which extends the logs to point out name of repo should it encounter permission issues (INFO
level for now).
Would you be able to pull the changes and then run the below query (it'll probably eat up a lot of your rate limit for the hour).
select
r.owner_login,
r.name,
c.user_login,
c.permission
from
github_my_repository r,
github_repository_collaborator c
where
r.name_with_owner = c.repository_full_name;
However, should you encounter the You do not have permission to view repository collaborators.
error, the offending repo should be findable in the logs by looking for insufficient_permissions
, this will help us in establishing a root cause.
Just for audit trail, feedback received.
Describe the bug
My pat has the following scopes:
Steampipe version (
steampipe -v
) Steampipe v0.20.6Plugin version (
steampipe plugin list
) 0.28.1To reproduce
Expected behavior should return results, without errors
Additional context Add any other context about the problem here.