I want to know if a Github repository has defined a certain service hook (Webhook URL) but I am not the owner of the repos (though I am a collaborator).
Is there a way to do that via the API (or any other programmatic way)?
If it helps, the repository in question may sometimes belong to an individual and sometimes to an organization.
I confirm the OP's conclusion:
It does not work. If I authenticate as the owner of the repo, it does work.
That means the List query (GET /repos/:owner/:repo/hooks) won't work if you are not owner (or admin for an organization) of a repo.
The Hooks GitHub API does mention:
The Repository Hooks API allows repository admins to manage the post-receive hooks for a repository.
Update February 2014: "New scopes for managing repository hooks"
You now can see hooks for a repo you don't own, provided the owner set the right scope:
Many third party services need to set up hooks in order to act upon events in your repositories.
We’ve introduced three new scopes that provide more granular access to your repository hooks without allowing access to your repository contents:
read:repo_hook grants read access to hooks in public or private repositories.
write:repo_hook grants read and write access to hooks in public or private repositories.
admin:repo_hook grants read, write, and delete access to hooks in public or private repositories.
Related
TLDR -
I want users of my employer's organization who install my CLI tool to be able to use it to run commands that use the GitHub rest api that require permissions the user doesn't personally have, while restricting the user from using the CLI tool to perform unintended actions with the elevated permissions needed by the CLI tool. Is there a way to create a CLI tool that 1. uses permissions the users of the CLI tool don't have while at the same time 2. prevents those users from using the CLI tool's elevated permissions to perform unintended actions?
Extended -
I'm building a CLI tool for my employer's organization so that the organization members can automatically create a new branch and simultaneously add branch protection and create a PR. As far as I know, updating branch protection with the GitHub API requires admin access. However, not all of the users who use this CLI tool will personally have those permissions for their user account. But a user in the organization should still be able to use the CLI tool (which uses permissions the user potentially doesn't have).
I thought about using a personal access token so that the users aren't using a single set of centralized credentials (github app creds), but then the CLI tool would have access to at least one of the user's personal repositories and potentially wouldn't have the required permissions required by the CLI tool.
So is there a way to build a tool as a package that can be installed on a users machine that...
has permissions that the user of the tool potentially doesn't have and
prevents the user from doing anything unintended. e.g. the tool (which has admin permissions) can add branch protection rules, but the user shouldn't be able to use the tool's elevated permissions for anything else - e.g. getting the interaction limits for an organization
prevents the user from using the tool in any organization repo they don't have access to.
Ok, that's the gist of it, but I will go into more detail in case that helps.
So currently I'm using a GitHub app and giving it the required permissions (e.g. admin read/write for branch protection rules). I'm using octokit to authenticate to the GitHub API with the GitHub App. To do this, I'm passing in the app id, private key, and the installation id.
package structure
- .env
- authenticate_and_do_stuff.ts
authenticate_and_do_stuff.ts
// authenticate with GitHub app creds
// see https://github.com/octokit/octokit.js#authentication
const octokit = new Octokit({
authStrategy: createAppAuth,
auth: {
appId: process.env.GITHUB_APP_APP_ID,
privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
installationId: process.env.GITHUB_APP_INSTALLATION_ID,
},
});
// create branch, add branch protection, etc.
octokit.rest.do stuff ...
This isn't ideal because then the user who installs the package needs those environment variables to be authenticated. And once they have those creds, they would be able to use them to do other things they potentially don't have permissions for (e.g. with the admin read/write permission the GitHub app has permissions for). So my thought is to have the user provide the authentication credentials that aren't the Github app credentials. This way, each user is using different credentials they provide. As for the reasons stated above, personal access tokens cannot be used. So the ideal situation is as follows -
A user installs the package - npm i my-github-cli-tool.
- node_modules
|
--- my-github-cli-tool
|
--- authenticate_and_do_stuff.ts
|
- some_custom_app_file.ts
- .env.cli_tool
They generate credentials and put them into a custom env file e.g. .env.cli_tool.
They use the CLI tool to create a new branch in an organization repo they have access to, create the branch protection rules (with the admin read/write access that the user doesn't have, but the credentials in step 2 has).
If the user tries to alter the cli tool or use the credentials in step 2 to use it to access repos they don't have access to or perform other actions with the admin read/write permissions, they shouldn't be able to.
If I stick with using the GitHub app, the source code on the user's machine has to get the credentials somehow. And those credentials need to have elevated permissions that the user might not have. So if these credentials are exposed to the source code on the user's machine, doesn't that mean the user can just grab those credentials and use them for nefarious purposes?
I need to restrict permissions for certain branches across 50 repos for specific user groups in azure repos. This is to say, a particular group of users cannot force push to the master branch but can other branches.
This is easy enough to do in the interface, but requires going to 50+ repos and manually performing this task. I've been reading through the Azure repos API documentation and I'm struggling to see how I go about setting this?
As explained in the blog post https://jessehouwing.net/azure-devops-git-setting-default-repository-permissions/:
tfssecurity /a+ "Git Repositories" repoV2/<Team Project GUID>/<repository guid>/refs^heads^<branch name>/ "ForcePush" <memberIdentity> DENY /collection:https://dev.azure.com/{organization}
The repository guids can be found out via REST API, where GitRepository.id contains the guid:
https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-5.1#examples
See https://learn.microsoft.com/en-us/azure/devops/server/command-line/tfssecurity-cmd?view=azure-devops for more information about how to specifiy member identity.
You can use below rest api to set branch permission fors for group.
POST https://dev.azure.com/{orgname}/{projectid}/_api/_security/ManagePermissions?__v=5
Here is a sample of request body.
{"updatePackage":
"{\"IsRemovingIdentity\":false,
\"TeamFoundationId\":\"{teamfoundationId}}\",
\"DescriptorIdentityType\":\"Microsoft.TeamFoundation.Identity\",
\"DescriptorIdentifier\":\"{DescriptorIdentifier}}\",
\"PermissionSetId\":\"2e9eb7ed-3c0a-47d4-87c1-0ffdd275fd87\",
\"PermissionSetToken\":\"repoV2/{projectId}}/{repoId}}/refs^heads^{branchname}}/\",
\"RefreshIdentities\":false,
\"Updates\":
[{\"PermissionId\":1,\"PermissionBit\":32768,\"NamespaceId\":\"2e9eb7ed-3c0a-47d4-87c1-0ffdd275fd87\",
\"Token\":\"repoV2/{projectId}/{repoId}/refs/heads/{branchId}/\"}],
\"TokenDisplayName\":null}"}
Note
\"PermissionId\":1, means set the permission to Allow,
\"PermissionId\":2, means set the permission to Deny,
\"PermissionId\":1, means set the permission to Not Set.
\"PermissionBit\":32768 is the Bypass policies when completing pull requests permission.
\"PermissionBit\":128 is the Bypass policies when pushing permission.
\"PermissionBit\":4 is the Contribute policies when pushing permission.
\"PermissionBit\":2048 is the Edit polices permission.
\"PermissionBit\":8 is the Fource push permission.
\"PermissionBit\":8192 is the Manage permissions.
\"PermissionBit\":4096 is the remove other's lock permission.
Addition
There are too many parameters in the request body, you can get there parameters by offical documentations. Or I recommand you to get these parameters by using Network Tool to manual cathch them.
According to GitHub API documentation, I can't get what scope I should use to ask to user to let me download his public/private repo, in read-only manner.
Currently I'm using repo but as you can read in the docs it:
Grants read/write access to code, commit statuses, invitations,
collaborators, adding team memberships, and deployment statuses for
public and private repositories and organizations.
But I don't want to ask to the user the permission to write on his repos!
That was requested in 2015, and two years later, the GitHub Platform Roadmap does mention a "Granular access permissions".
But for now, read-only access is not yet part of the available scopes.
A possible workaround would be to setup a mirror repo, and on each commit on the first original repo, force pushing (overriding) said commit to the second repo (obliterating any write/modification done on that second repo)
I need to develop a bunch of my own web hooks (or services maybe) for auto deploy, report into project management systems, etc.
But data posted to web hook don't have much information to fill my needs.
For example, I've received simple push event, how can I know is it force push or not? Okay, I have 2 treeishes, let's look at repository and check this push — oops, need user token to do it. Sad.
What is the right method to access gitlab api from web hooks? Probably I've missed something important? I'm really confused.
Upd1:
Let's try to find a solution. Possibilities
Imagine we can have a user who can read all projects in gitlab. But
that user should be connected to each project to have an access. Ok
;-(
What about to read repo by pusher? We can't because we need to use his private token to do this.
Maybe some internal functionality to read all repos or something? Sure not.
So. Maybe database? Nope. Because we need to clone repo at first and can't save data in DB anyway with refreshing caches.
I think we need a security token and maybe many checkboxes with access permissions for each joined web hook or an app (service).
Please feel free to share your ideas.
I've remembered partial solution. So scenario will be like that:
Create web service with your web hook.
Create a ssh key on the same host for some special (usually owner of web hook service) user to have an access to repos.
Add ssh key created at previous step as deploy key.
Finally: Register your webhook and add your deploy key for that hook to project — repeat it for each project what need this hook.
You have event listener (your web hook service), and you have access to that repository (ssh/git).
But still that solution doesn't have access to API itself.
Probably, there is also an another solution.
Create custom admin user with a big random password and some synthetic name like HookBot or something, remember private_token of that user;
Register your web hook;
Use api access to add your deploy key with HookBot (untested);
Use sudo api to get sources or something else. Just mimicry to pusher's account (sudo -u {author_id}) and go on, read repo, work with it, etc.
Maybe some another solutions? More legit?
I'd like to add a private Github repo for my organization to BuildHive but for some reason they aren't showing in the "Add Projects from GitHub!" page.
Is there someway to add these or are private repos not yet supported? Is there some paid subscription service for BuildHive I can use to get this support?
BuildHive is an intentionally simple build service: only open-source (or at least public) repositories supported, only on GitHub, and with minimal configuration options. If you want any other options, you can subscribe to the DEV#cloud service to get a Jenkins instance that you can configure however you like, including access to password-protected version control.