Add support for enterprise platform like GitHub Enterprise

[kadary]

Hello,

I think it will be a great feature if we can use Vssue in our entreprise Platforms.

Look at your GitHub API for example, in it's constructor, the API endpoint is hardcoded (https://github.com/meteorlxy/vssue/blob/master/packages/%40vssue/api-github-v3/src/index.ts#L39). A oiding this and just using public GitHub API as default one will let's some users as me to integrate Vssue with other GitHub server deployment like it's the case for GitHub Enterprise.

If you want, I can make a pull request for these feature.

[meteorlxy]

I'm not familiar with Github enterprise. Does the baseURL option help? Could you provide docs of github enterprise?

[kadary]

As state by GitHub Enterprise developper Doc, your concept of baseUrl can help customizing Vssue to use a Gh Enterprise server. This is the link to the doc: https://developer.github.com/enterprise/2.16/v3/enterprise-admin/.

As a user the baseUrl can help me provide other endpoint to reach a GitHub servers API than the public GitHub servers (https://api.github.com)

[meteorlxy]

@kadary Thanks! So the API pattern of Github Public API and Github Enterprise API is compatible, right?

• Github Public API V3 endpoint: https://api.github.com/v3
• Github Enterprise API V3 endpoint: http(s)://hostname/api/v3

I'll refined the docs about that.

[meteorlxy]

@kadary The Authentication might be different. Could you please help to check if our current api-github-v3 / api-github-v4 works with Github Enterprise?

[meteorlxy]

These may not work well, as they are hard-coded to github.com:

https://github.com/meteorlxy/vssue/blob/0cded762da3d1d80d2e587780c147ab93bc59aae/packages/%40vssue/api-github-v3/src/index.ts#L92-L94

https://github.com/meteorlxy/vssue/blob/0cded762da3d1d80d2e587780c147ab93bc59aae/packages/%40vssue/api-github-v3/src/index.ts#L145-L147

[kadary]

Hello,

Yes api-github-v3 works with github enterprise. I have never use api-github v4. But I can check that during next week.

the authorization endpoint will work by changing just the hostname to endprise server hostname (change https://github.com by https://github.mycompany.com) : https://github.com/meteorlxy/vssue/blob/0cded762da3d1d80d2e587780c147ab93bc59aae/packages/%40vssue/api-github-v3/src/index.ts#L92-L94

And the logic can be:

• if a BaseUrl is provided eg: https://github.mycompany.com :
  • calling REST API is done by appending baseUrl with /api/v3
  • Calling OAuth2 endpoint is done by only using baseUrl as provided
    • else Use public github endpoints

But I Think CORS proxy can be the blocking point since your CORS anywhere instance will not see any github Enterprise endpoint. Hopefully, many enterprises provide inhouse CORS Proxy for these kind of usage. So You can also add an optional config option to provide a custom GITHUB server token endpoint. to use here (eg: _https://cors-proxy.company.com?target=https://github.mycompany.com/login/oauth/access_token_): https://github.com/meteorlxy/vssue/blob/0cded762da3d1d80d2e587780c147ab93bc59aae/packages/%40vssue/api-github-v3/src/index.ts#L145-L147

All these make me think about something:

1- Cors anywhere is used for all your API requests to github since GitHub does not support CORS 2- GitHub app secret is present in frontend JS wich is a high security risk.

Why did you not provide a simple node server as an option to handle all these for you.

I know it's more complicated to operate but these can be a killing feature that encourage large Enterprise to use Vssue in place of other tools like gitalk, gitment... The node server can be just an optional companion app Wich can reuse your API packages in a secure maner. And the advantages will be:

• No hidden SPOF (ref cors-anywere)
• more secure for handling Oauth2 secret
• much robust and portable by respecting providers CORS policies.

And if you think it can help Vssue to get it's next gap, I can help you with the companion backend server.

[meteorlxy]

Thanks so much about your advice.

About CORS

Only the API for getting access token does not support CORS, so we choose a third party cors-anywhere to handle that.

• The author of Gitment make a cors proxy himself which is not stable.

• Gitalk use cors-anywhere by default, and have an option proxy to change it.

It's a good idea to add a similar option in Vssue.

About Security

Gitment and Gitalk also hard-code app secret in JS file (see https://github.com/imsun/gitment#is-it-safe-to-make-my-client-secret-public).

But yes, this has potential risks.

I have ever found a possible solution in Netlify: https://www.netlify.com/docs/authentication-providers/.

So we can build a service like Netlify does. Users can config their cliendId and cliendSecret in our service, and our service gets the access token for users. If so, there would not have CORS and Security problems.

If this problem be solved, it will be one of the important advantages of Vssue, and we can release 1.0 version. It will be nice if you have time to help make Vssue better :wink:

[kadary]

For gitment, I have filled an issue in gitment(https://github.com/imsun/gitment/issues/179).

Yes providing a HA service like netlify can be a good option. I will try to push to you a pull request for these feature with also GH Enterprise support

[meteorlxy]

Gitment is not maintained for a long time, I'm afraid that you won't get reply 😅

Maybe we need to create another repo for the individual service

[meteorlxy]

Found a repo: https://github.com/prose/gatekeeper

[Realvincentyuan]

Hi @meteorlxy,

wonder what is the solution for enterprise Github?

• Simply updating base_url with enterprise path does not work, as it looks that it fails in the authentication with a 403 error.
• And the client_secret was explicitly specified in the front end so it is against the company's policy so it is even unable to be pushed to the deployment environment.