github enterprise oauth support

[maxxedev]

Hi,

How can remark42 be configured for github enterprise, where github is self-hosted at https://github.internal-network.company.com ? remark42 can authenticate with github only at the public URL: https://github.com ?

thanks

[umputun]

GitHub provider implemented by go-pkgz/auth, and the implementation is tiead to api.github.com

I'm not familiar enought with the github enterprise and don't have any instance to test it, but I would think on-premise instance may provide a similar api on the internal (self-hosted) url.

In order to support github enterprise provider, it should be added to go-pkgz/auth first. Integrating it into remark42 will be trivial.

[maxxedev]

I tried by changing the oauth urls in backend/vendor/golang.org/x/oauth2/github/github.go but I see an error like this:

exchange failed - oauth2: server response missing access_token - 500 - 1.2.3.4-
/auth/github/callback?error=redirect_uri_mismatch
&error_description=The redirect_uri MUST match the registered callback URL for this application.
&error_uri=https://docs.github.com/enterprise/2.22/apps/managing-oauth-apps/troubleshooting-authorization-request-errors/#redirect-uri-mismatch
&state=3083a3f5f18684cfa6caf42c34668bf711a76a53
[caused by auth/provider/oauth2.go:150 provider.Oauth2Handler.AuthHandler]

The URL does seem to match. Not sure what's going on.

[umputun]

Have you tried to change all 3 urls? 2 in oauth2.Endpoint and infoURL ?

[umputun]

btw, redirect_uri_mismatch usally means incorrect url in "Authorization callback URL" param set on github side

[maxxedev]

Fabulous. It works now. I was able to get past oauth problem by adjusting the ports bit in remark42 docker config:

- REMARK_PORT=<plain-port>
- REMARK_URL=https://internal-host:<secure-port>
- SSL_PORT=<secure-port>

And setting callback URL to this in github:

https://internal-host:<secure-port>/auth/github/callback

Thanks for the pointer about infoURL. I changed the value:

// in backend/vendor/github.com/go-pkgz/auth/provider/providers.go
https://github.internal/api/v3/user

Otherwise I saw "Invalid comment data" error message

I can post comments now. Avators don't work though. Any idea?

[umputun]

not sure what https://github.paypal.com/api/v3/user supposed to represent. This should be {internal-github}/api/v3/user url (or whatever ghe uses for this) and this URL is actually used to get info about user including avatar's url. It is mapped here to avatar_url fields from that /user response.

See https://docs.github.com/en/rest/reference/users#get-the-authenticated-user for more details

hope it helps.

P.S. If you make it work pls consider submitting PR to go-pkgz/auth

[maxxedev]

I think avatars don't work for enterprise github requires login:

https://github.internal/avatars/u/1234

Compare that to public github:

https://avatars.githubusercontent.com/u/1234

[maxxedev]

remark42 proxies the avatar url like this:

https://remark42-server/api/v1/avatar/1234.image

Is it possible to render raw URL? like:

https://github.internal/avatars/u/1234

[umputun]

it proxies images only after it can get one. This is, in fact, not a proxy, but a local copy of the avatar. This done intentionally because many providers don't like hotlinking

[umputun]

If your theory about "avatars don't work for enterprise github requires login" correct, this issue probably can be addressed by initiating authenticated call inside/around this mapping function. In theory, here we may know auth token and should be able to access protected resources

[maxxedev]

Not sure about programmatic oauth users but for human users, authentication might be multi-factor authentication, so it might become complicated. I think hotlinking option would be an easy way out, where users are presumably authenticated in the browser already.

[umputun]

I think, at this point user already passed all auth handshakes, multifactor or not and programmatic access should be as easy as sending Authorization header

Hotlinking is a troublesome workaround. First of all, this is not that easy to do in the current auth model, and the second issue - most likely it will hit github limits. If some discussion has just 100 comments in (not that crazy size) it will try to hit ghe API with 100 image requests right away. Probably after the first hit it can be served from the cache but still unhealthy load.

[umputun]

fyi: this is the place this infoURL got the hit https://github.com/go-pkgz/auth/blob/master/provider/oauth2.go#L155

as you can see it happens inside of AuthHandler and you should be able to get auth token from oauthClaims

[paskal]

Resolving this issue in favour of go-pkgz/auth#75, feel free to reopen if I'm wrong.