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

Support API token as credentials for git https (GitHub...)

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-client-plugin
    • Docker Pipeline 1.14

      GitHub recommends for git+https to use API tokens instead of username & password.

      GitHub API token can be passed as a real token (https://<token>@github.com/username/bar.git) or as the username of a username:password auth (https://<token>:@github.com/username/bar.git).

      The client-client-plugin only supports username-password credentials for the moment (see o.j.p.gitclient.CliGitAPIImpl#getGitCredentialsURL()).

      Using a username-password-credentials storing the token in the username field is not a valid workaround as the GitHub API token is revealed in the GUI (see attached screenshot).

      Could we add support for Token as credentials for git+https and, if possible, introduce a credentials named "Token" as this name is more intuitive than "Secret Text".

          [JENKINS-33174] Support API token as credentials for git https (GitHub...)

          Mark Waite added a comment -

          The plugin already supports GitHub API tokens in its current steps. I create a new credential with my user name, and with the API token as the password, then reference that credential from the job definition. Does that not work for you?

          Is there something more to be gained by calling the password an API token?

          Mark Waite added a comment - The plugin already supports GitHub API tokens in its current steps. I create a new credential with my user name, and with the API token as the password, then reference that credential from the job definition. Does that not work for you? Is there something more to be gained by calling the password an API token?

          Thanks markewaite for the quick answer.

          > I create a new credential with my user name, and with the API token as the password, then reference that credential from the job definition. Does that not work for you?

          You are right, I forgot that we could store the token in the password field and use the account name as username.

          > Is there something more to be gained by calling the password an API token?

          I feel it would be more intuitive as GitHub call them tokens and not password and as my understanding is that GitHub API tokens don't require to provide a username.

          This question is more about the philosophy on how to filter credentials in Jenkins. I see benefits in adding more credentials types, jglick told me that his vision is to leverage credentials domains.
          I'll try to mockup different use cases.

          Cyrille Le Clerc added a comment - Thanks markewaite for the quick answer. > I create a new credential with my user name, and with the API token as the password, then reference that credential from the job definition. Does that not work for you? You are right, I forgot that we could store the token in the password field and use the account name as username. > Is there something more to be gained by calling the password an API token? I feel it would be more intuitive as GitHub call them tokens and not password and as my understanding is that GitHub API tokens don't require to provide a username. This question is more about the philosophy on how to filter credentials in Jenkins. I see benefits in adding more credentials types, jglick told me that his vision is to leverage credentials domains. I'll try to mockup different use cases.

          Mark Waite added a comment -

          I use credential domains already with my GitHub API token. I assign the GitHub user name and password to only be displayed for the domain "github.com" . It works quite well. I have it included in my Jenkins server docker image that I use for fast setup and teardown of interactive tests.

          Mark Waite added a comment - I use credential domains already with my GitHub API token. I assign the GitHub user name and password to only be displayed for the domain "github.com" . It works quite well. I have it included in my Jenkins server docker image that I use for fast setup and teardown of interactive tests.

          markewaite when I discussed with jglick, I imagined that we could enhance the behavior of the "add credentials" button in the job config page to inject a default domain and to restrict the type of credentials to match what the plugin declaring the "add credentials button" supports.

          Cyrille Le Clerc added a comment - markewaite when I discussed with jglick , I imagined that we could enhance the behavior of the "add credentials" button in the job config page to inject a default domain and to restrict the type of credentials to match what the plugin declaring the "add credentials button" supports.

          Mark Waite added a comment -

          My apologies, but I don't understand how your description is different from the current behavior.

          When I add a git repository to a job definition, the user interface only shows those credentials which match the domain specification of the repository which was added. If the domain specification limits the credential to hostname = "github.com", then only global credentials and credentials specified for "github.com" will be presented. The credentials assigned to the "bitbucket.org" domain or to the "gitlab.com" domain are not visible in that context.

          Can you further clarify what you're expecting to see change?

          Mark Waite added a comment - My apologies, but I don't understand how your description is different from the current behavior. When I add a git repository to a job definition, the user interface only shows those credentials which match the domain specification of the repository which was added. If the domain specification limits the credential to hostname = "github.com", then only global credentials and credentials specified for "github.com" will be presented. The credentials assigned to the "bitbucket.org" domain or to the "gitlab.com" domain are not visible in that context. Can you further clarify what you're expecting to see change?

          I'm preparing a mockup to explain my idea.

          Cyrille Le Clerc added a comment - I'm preparing a mockup to explain my idea.

          markewaite Sorry for the delay, I didn't give up on this, I am first presenting my ideas to stephenconnolly and I'll shared my thoughts with the community.

          Cyrille Le Clerc added a comment - markewaite Sorry for the delay, I didn't give up on this, I am first presenting my ideas to stephenconnolly and I'll shared my thoughts with the community.

            Unassigned Unassigned
            cleclerc Cyrille Le Clerc
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: