-
New Feature
-
Resolution: Unresolved
-
Minor
-
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
- is related to
-
JENKINS-72295 Support bearer token authentication in the git plugin
-
- Open
-
- links to
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