Our organization is moving away from Gitlab to Github enterprise. and this would involve authentication specific changes for our app.
Our app includes a front end. With every event on the front end, an api* call is made. This API in turn currently hits Gitlab (using gitlab's api) and a private token to commit/branch/push/pull on the repo.
Now, I am trying to work up a similar structure when we migrate to github. From what I have read, github uses oAuth2.0 to authenticate.
Following the documentation, I have followed following steps until now :
Created an organization.
Added a sample repo to it.
Registered my api* (the entity that interacts with the front end) with the organization. This helped me generated a client_id and client_secret.
Now, I have been trying to retrieve an oAuth token using github v3 api but I end up getting an exception :
"message": "Requires authentication"
So I am pretty confused now on where to go from here. May be I understood it all wrong ?
If somebody could aide me with this or suggest an alternative, that shall be great.
Related
At my company, we have a CLI which allows our customers to upload data to our backend solution. The CLI runs on PR changes within a job. Let's assume the uploaded data looks like this:
{
name: "John",
age: 20,
}
Once the upload is completed, I'd like to create a comment on the PR with to following body:
John is 20 years old.
I've found the following ways to do this:
GitHub App (a bot)
GitHub OAuth App
Personal Access Token
GITHUB_TOKEN
GitHub App
The GitHub App needs to do the following things:
Fetch the data via a user-specific API key
Create a comment
I already created a comment via a bot, but I have no clue how to fetch the data.
As far as my understanding goes, I'd like other users to be able to install this GitHub app from the marketplace to work out of the box. From the ProBot Docs I understand that the bot operates on a webhook basis. Meaning I need to subscribe to a 'job completed' event (not sure if that's the correct name but I think you get the idea) and then fetch the data via a user-specific API we are providing on our platform. However, I see no way for the user of our App to configure an API key (or any form of secret) so the bot can make authenticated requests to our endpoints.
I'd prefer to use GitHub App because the comment coming from the bot would have our company branding and also an indicator that this comment has been created by the integration.
OAuth App
I already tested this by using Postman, however, the comment looks like it's coming from a specific user. Therefore, it has no company branding and it's not clear that an integration created the comment. However, the great part is that we could integrate this with our application, so our backend could create the comment once the data is received.
What I like about this approach is that we also need to implement such a feature for GitLab, Azure, etc, and using OAuth likely scales well with the other providers in comparison to the GitHub app, which is GitHub-specific.
Personal Access Token
Works pretty much like the OAuth App, but instead of our backend creating the comment, the comment is created by the CLI (and the access token is passed into the CLI). However, I think this approach is a bit sketchy.
GITHUB_TOKEN
While I haven't tried this yet, I assume that the token has limited but sufficient permissions to create a comment. As of now, I don't know what the comment will look like, but I think we can rather safely pass this into the CLI to create the comment from there. Since the permissions are limited and the token is invalidated after the workflow I see limited risk for the user of our CLI (and services).
Edit: The comment is coming from the github-actions bot, which is not the branding we are looking for, but it's clear that the comment has been created by the integration.
Questions
What's the best way to accomplish what I am trying?
Is there any way I can make this work with GitHub Apps (aka bots)?
Much has been written about the benefits of the GitHub GraphQL API. And this is a really great technology. The only thing I can't figure out is in what situations is it still better to use the good old REST API v3?
Github GraphQL API is subject to the following caveats:
GraphQL API can only be accessed using authentication. You need a token to use this API. Thus, you can't use GraphQL in an environment where you can't secure the provisioning of this token. For example, in a web app without github authentication. This is a big caveat, especially for people who want to create web app or scripts that target only public repository informations.
Searching commits and code using the search API is not possible in Github Graphql. Only searching repos, issues and users are supported (for the search API)
some features like comparing commits and getting contributors are not possible yet in Graphql. Another example: you can't recursively get a tree using GraphQL API
some mutations already available in v3 may not yet have been implemented in GraphQL (create commit, create tag, create branch etc...), checkout mutations documentation
So, As github is deprecating authorization through access_token query param, we were sent a mail from github that a call has been made with access_token in query param and were asked to update things to include authorization info in request headers.
We are suspecting that the api call is made from Jira confluence app from the github integration that was done by admin which we don't have control over.
So, just trying to debug things here. Does anyone know how Jira confluence internally communicates with Github servers using access_token to update pull requests and commits etc in Jira tickets?
If this is not the correct domain for this please move it to the right one.
It is very possibly the Github/Jira integration. This bug ticket was resolved in August but based on the comments there it's not completely fixed or released.
This issue has some back-and-forth but this comment clears things up: it looks like GitHub recommends uninstalling the old Jira integration and using the one GitHub maintains instead.
I've finally got the beta services added to my bluemix project.
But it's not very clear how the integration with slack should be configured.
I have an account, team, and channel already. The link in the instructions points to OAuth authentication. Your options are to register an app (but for that you need to know things like the secret, redirecting URI, etc). That can't be right...
Are there any more details available on how to configure Slack for a bluemix project?
If you look at the linked documentation here: https://api.slack.com/web#authentication
There are 2 ways to authenticate with Slack. The first is to use a generated full-access token and the second is to register the application and use OAuth 2 with Slack.
Currently, the Bluemix project beta supports the first method of authentication only. If you are logged into your Slack team(s) and go to the link above, you should see the option to generate tokens for each of the Slack teams you are a part of. That is the token you will need to enter when configuring the Slack integration on the integrations page for your Bluemix project. The other field that you must fill in is the Slack channel that you want to post events to, which you already seem to have.
Screenshot:
Screenshot indicating location of the token you must copy
We have an web application, which lets the user write code and store it in an internal git repository on our server.
Now we wanted to allow the user to share his code with his github repository. So we looked through the api documentation of github and found a way via ouath2.
However to make this work, we need to request write access from the user, but github oauth access scopes only include write access to all repository of an user, which is way too much for us.
Is it possible to restrict an api access for only one specific repository of an user?
As per jasonrudolph comment, it is not currently possible to restrict API access to a specific repository.
Deploy keys are the closest thing that provides this type of functionality. (This won't help you from an API perspective, but a deploy key might meet your underlying need.) If your application were to generate an public/private SSH keypair, and the user were to add the public key as a deploy key in the repository, then you could use the private key to access just that one repository (without having access to the user's other repositories).