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

Add support for http.extraHeader for bearer token authentication

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-client-plugin
    • None

      Bearer Tokens are sometimes very useful to connect to git repositories. From principle what is needed here is a smart integration from the git plugin with a secret (secret text for instance) to achieve a git call with

      -c "http.extraHeader=Authorization: Bearer ..."
      

      Bitbucket documentation for HTTP access tokens:
      https://confluence.atlassian.com/bitbucketserver/http-access-tokens-939515499.html

      Azure DevOps documentation for "Use personal access tokens":
      https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows#use-a-pat

          [JENKINS-70897] Add support for http.extraHeader for bearer token authentication

          nils m added a comment -

          For the CliGitAPIImpl only a single change would have to be made to the launchCommandWithCredentials method (https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2082)

           

          Currently it differentiates between SSHUserPrivateKey and StandardUsernamePasswordCredentials. A third branch would be needed to handle what is referred to as Secret Text in the Jenkins UI (probabaly StringCredentials).
          As the args is list already in scope in the method we would only need to append the -c extraHeader=.... argument to it and would be good to go.

          There is an alternative way to set the extra header through environment vars for new git version >=2.31, see: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/716#issuecomment-1579002395
          This would lessen the risk of exposing bearer tokens through e.g. the process list on multi user system setups

          nils m added a comment - For the CliGitAPIImpl only a single change would have to be made to the launchCommandWithCredentials method ( https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2082)   Currently it differentiates between SSHUserPrivateKey and StandardUsernamePasswordCredentials. A third branch would be needed to handle what is referred to as Secret Text in the Jenkins UI (probabaly StringCredentials). As the args is list already in scope in the method we would only need to append the -c extraHeader=.... argument to it and would be good to go. There is an alternative way to set the extra header through environment vars for new git version >=2.31, see: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/716#issuecomment-1579002395 This would lessen the risk of exposing bearer tokens through e.g. the process list on multi user system setups

          HelloWorld added a comment -

          Hello , can I work on this issue ? 

          HelloWorld added a comment - Hello , can I work on this issue ? 

          Mark Waite added a comment -

          An implementation proposal for command line git is available as https://github.com/jenkinsci/git-client-plugin/pull/1104 . The matching git plugin implementation pull request is https://github.com/jenkinsci/git-plugin/pull/1566

          Mark Waite added a comment - An implementation proposal for command line git is available as https://github.com/jenkinsci/git-client-plugin/pull/1104 . The matching git plugin implementation pull request is https://github.com/jenkinsci/git-plugin/pull/1566

          Kamil added a comment -

          Hi, I sincerely hope you manage to implement this solution

          Kamil added a comment - Hi, I sincerely hope you manage to implement this solution

          The Azure documentation read something like this export HEADER_VALUE=$(echo -n "Authorization: Basic "$(printf ":%s" "$MY_PAT" | base64)). So Authorization Basic and not Bearer..
          Has anybody been able to use Jenkins Username / Password credentials with an empty username and the PAT as password as a workaround in the meantime ?

          Allan BURDAJEWICZ added a comment - The Azure documentation read something like this export HEADER_VALUE=$(echo -n "Authorization: Basic "$(printf ":%s" "$MY_PAT" | base64)) . So Authorization Basic and not Bearer.. Has anybody been able to use Jenkins Username / Password credentials with an empty username and the PAT as password as a workaround in the meantime ?

            Unassigned Unassigned
            mguillem Marc Guillemot
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: