Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43214

Support for multiple jenkins master with one github application using redirect uri

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • github-oauth-plugin
    • None
    • github oauth plugin 0.25
      jenkins 2.46.1

      Hello.

      In my company, we use github enterprise on premise and a lot of jenkins for many department. That is, there are multiple jenkins masters here. 

      To use github oauth plugin, people have to make their application in github to get their clientId and client secret per jenkins master. But I think it is redundant.

      If we can use "redirect urls" of github oauth, we don't need to make that many jenkins applications in github. You can find more information here

      To be specific, we can set different redirect uri in each jenkins master for their "finish login url" with same client ID and client secret. Then we just need one github application for the client ID and the client secret.

      However, it seems not possible to set redirect uri with github oauth plugin. So I could change it to support multi-master jenkins.

          [JENKINS-43214] Support for multiple jenkins master with one github application using redirect uri

          Sam Gleske added a comment -

          I think this improvement makes sense.  Contributions are welcome.

          Sam Gleske added a comment - I think this improvement makes sense.  Contributions are welcome.

          Fred Vogt added a comment -

          https://github.com/jenkinsci/github-oauth-plugin/pull/111 Addresses this.

          https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#redirect-urls

          Would be nice to get it reviewed and merged.

          It appears that the Github OAuth app URL would have to be a virtual host.

          Jenkins servers would then pass the redirect URI sub-path.

          Example:

          Github OAuth App Callback URL:
          https://jenkins.example.com/github-oauth
          
          Redirect URL: 
          https://jenkins.example.com/github-oauth/<environment>/<instance>/securityRealm/finishLogin
          
          Where the vhost 'jenkins.example.com/github-oauth' using path based routing to proxy the callback to the correct jenkins server:
          https://jenkins-<instance>.<environment>.example.com/securityRealm/finishLogin

          Fred Vogt added a comment - https://github.com/jenkinsci/github-oauth-plugin/pull/111  Addresses this. https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#redirect-urls Would be nice to get it reviewed and merged. It appears that the Github OAuth app URL would have to be a virtual host. Jenkins servers would then pass the redirect URI sub-path. Example: Github OAuth App Callback URL: https: //jenkins.example.com/github-oauth Redirect URL: https: //jenkins.example.com/github-oauth/<environment>/<instance>/securityRealm/finishLogin Where the vhost 'jenkins.example.com/github-oauth' using path based routing to proxy the callback to the correct jenkins server: https: //jenkins-<instance>.<environment>.example.com/securityRealm/finishLogin

          Fred Vogt added a comment -

          sag47 - using a build of 0.34-snapshot with PR-111 merged, conflicts fixed I was able to confirm his changes work as expected.

          For compatibility having a constructor overload with the old signature in the GithubSecurityRealm:

          new GithubSecurityRealm(githubWebUri, githubApiUri, clientID, clientSecret, oauthScopes,)
          
          new GithubSecurityRealm(githubWebUri, githubApiUri, clientID, clientSecret, oauthScopes, redirectUri)
          

          I commented in the PR how I tested this.

          This is great. I've wanted this for a long time. What do we have to do to get this into 0.34 ?

          Fred Vogt added a comment - sag47 - using a build of 0.34-snapshot with  PR-111 merged, conflicts fixed I was able to confirm his changes work as expected. For compatibility having a constructor overload with the old signature in the GithubSecurityRealm : new GithubSecurityRealm(githubWebUri, githubApiUri, clientID, clientSecret, oauthScopes,) new GithubSecurityRealm(githubWebUri, githubApiUri, clientID, clientSecret, oauthScopes, redirectUri) I commented in the PR how I tested this. This is great. I've wanted this for a long time. What do we have to do to get this into 0.34 ?

          Basil Crow added a comment -

          What do we have to do to get this into 0.34 ?

          Just file a new PR against tip-of-trunk with merge conflicts resolved and this comment addressed.

          Basil Crow added a comment - What do we have to do to get this into 0.34 ? Just file a new PR against tip-of-trunk with merge conflicts resolved and this comment addressed.

            sag47 Sam Gleske
            shyr stephen moon
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: