GithubApp Auth

[loonydev]

Hi,
As I understand, for now this library don't support GithubApps authorization?

If so, I want to discuss the best way for implementation.

In my code I used trait GithubAuth with method def getAuthHeader():String. GithubClient taken instance of GithubAuth and call this function for token. In case of PAT it's return token from constructor, in case of private key it's looks like:

class GithubKeyAuth(privateKeyContent: String, appId: String) extends GithubAuth {

  implicit val clock: Clock = Clock.systemUTC
  // build PrivateKey instance from string
  private val privateKey = GithubKeyAuth.getPrivateKey(privateKeyContent)

 // generate valid JWT token using PrivateKey
  override def getAuthHeader(): String = {
    "Bearer " + Jwt.encode(JwtClaim({
      s"""{"iss":$appId}"""
    }).issuedNow.expiresIn(10), privateKey, JwtAlgorithm.RS256)
  }
}

WDYT?

[BenFradet]

You're right we don't support github apps authorization.
However, I'm not sure about the best way to go about it as we don't want to handle jwt tokens directly in the library for example.

[loonydev]

Agreed, maybe we can make GithubClient to accept instance of GithubAuth, so the user can use by default GithubPatAuth, in other cases they need to define own class.

But if it's part of Github Auth flow user will do same code over and over.

[loonydev]

So, do you have any suggestions how to implement it?
I can do that, by I need to be sure that I don't waste a time.

[BenFradet]

maybe we can make GithubClient to accept instance of GithubAuth, so the user can use by default GithubPatAuth, in other cases they need to define own class.

I'm 👍 on that

[loonydev]

But as I mention before, users will do same code over and over and not in the best way. It's like give them domain and say, use own http sender.

[BenFradet]

We can add that code as documentation, it doesn't seem to me like the usage will be so huge that it would need to be part of the library.

[loonydev]

Okay, next week I'm going to prepare this changes and will discuss it with real example.

[kusaeva]

@loonydev Hi! Are you still planning to make a PR with this changes?

[loonydev]

Morning @kusaeva, not yet, it's in plan, but not in a near future. If you have a time to make it, it would be great.

[nmcb]

Hello - I'm interested about the status of this issue

We have a standalone service in our infrastructure that requires broad access to GH's REST api and the repositories under our organisation (DHL-Parcel) - preferably using the github4s library and authorise not via a personal access token - but either via JWT tokens or - as requested in this issue - via GH Apps authorisation.

We did try the new AccessToken feature to get this working but weren't able to. The main issue seems to be the Authorisation: token header being hardcoded in the library, but we might not understand the way the new features was intended to be used. In that case an example would help us.

If authorisation via JWT or GH App tokens is currently not possible we would able to spend some time on getting this to work with github4s provided that we get some help and pointers on how the preferred integration should look like in the API.

Thanks in advance :)

[fedefernandez]

Hi @nmcb, thanks for your interest.

This is how it's currently built.

We have an algebra that allows generating tokens:

github4s/github4s/shared/src/main/scala/github4s/algebras/AccessToken.scala

Lines 31 to 34 in 9c18225

	trait AccessToken[F[_]] {
	def withAccessToken[T](f: Option[String] => F[GHResponse[T]]): F[GHResponse[T]]
	}

This algebra has a single implementation called StaticAccessToken. You pass a token, and it returns as a pure value.

github4s/github4s/shared/src/main/scala/github4s/interpreters/StaticAccessToken.scala

Lines 25 to 29 in 9c18225

	class StaticAccessToken[F[_]](accessToken: Option[String]) extends AccessToken[F] {
	override def withAccessToken[T](f: Option[String] => F[GHResponse[T]]): F[GHResponse[T]] =
	f(accessToken)
	}

When you create a new Github4s client, it's creates an instance of that algebra to use it internally:

github4s/github4s/shared/src/main/scala/github4s/Github.scala

Line 53 in 9c18225

new Github[F](client, new StaticAccessToken(accessToken))

This is then used to create the internal GithubAPIv3 algebra:

github4s/github4s/shared/src/main/scala/github4s/Github.scala

Line 31 in 9c18225

private lazy val module: GithubAPIs[F] = new GithubAPIv3[F](client, config, accessToken)

That, in a similar way, pass it to the internal HTTPClient algebra:

github4s/github4s/shared/src/main/scala/github4s/modules/GithubAPIs.scala

Line 32 in 9c18225

implicit val httpClient: HttpClient[F] = new HttpClient[F](client, config, accessToken)

The HTTPClient uses the withAccessToken to get the token and pass it to the RequestBuilder

github4s/github4s/shared/src/main/scala/github4s/http/HttpClient.scala

Lines 65 to 69 in 9c18225

	withAccessToken(accessToken =>
	runWithoutResponse[Unit](
	RequestBuilder(buildURL(url)).withHeaders(headers).withAuth(accessToken)
	)
	)

The RequestBuilder stores the token in a authHeader map, where the key is Authorization, and the value is s"token $token".

github4s/github4s/shared/src/main/scala/github4s/http/RequestBuilder.scala

Lines 44 to 48 in 9c18225

	def withAuth(accessToken: Option[String] = None): RequestBuilder[Res] =
	this.copy(authHeader = accessToken match {
	case Some(token) => Map("Authorization" -> s"token $token")
	case _ => Map.empty[String, String]
	})

This is mapped to a Header.Raw

github4s/github4s/shared/src/main/scala/github4s/http/Http4sSyntax.scala

Line 50 in 9c18225

self.authHeader.map(kv => Header.Raw(CIString(kv._1), kv._2))).toList

Potential solution

@loonydev's approach looks good, so I've created a draft with a potential solution:

• https://github.com/47degrees/github4s/pull/875/files

In that way, you can implement your algebra for generating auth headers, having complete control. Let me know your thoughts. The docs need to be updated accordingly.

[nmcb]

thanks @fedefernandez! we'll give it a try.

cc @thijsnissen