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

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

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: github-oauth-plugin
    • Labels:
      None
    • Environment:
      github oauth plugin 0.25
      jenkins 2.46.1
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          sag47 Sam Gleske added a comment -

          I think this improvement makes sense.  Contributions are welcome.

          Show
          sag47 Sam Gleske added a comment - I think this improvement makes sense.  Contributions are welcome.
          Hide
          build_admiral 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
          Show
          build_admiral 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
          Hide
          build_admiral Fred Vogt added a comment -

          Sam Gleske - 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 ?

          Show
          build_admiral Fred Vogt added a comment - Sam Gleske - 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 ?

            People

            • Assignee:
              sag47 Sam Gleske
              Reporter:
              shyr stephen moon
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: