[JENKINS-60709] base64 encoding support when binding usernameColonPassword

Would it make sense to have support for optionally have the value bound by usernameColonPassword base64 encoded?

The scenario is that I'd like to have ONE Username and password credential defined in my Jenkins instance, representing the (user) account in Nexus. I'd like to be able to use that for all access with NExus, e.g. Maven repos and npm registries.

When publishing to a npm registry in Nexus it is possible to use basic auth and hence this username/password credential, but it needs to be base64 encoded. Info here: https://help.sonatype.com/repomanager3/formats/npm-registry#NpmRegistry-AuthenticationUsingBasicAuth

My idea is to add an additional optional param for usernameColonPassword to be able to specify that the value should be base64 encoded before bound. Possibly it could generalized to support different encodings, should it make sense.

---
Originally reported by ahammar, imported from: base64 encoding support when binding usernameColonPassword

• status: Open
  
• priority: Minor
  
• component(s): credentials-binding-plugin
  
• resolution: Unresolved
  
• votes: 1
  
• watchers: 1
  
• imported: 20251211-141027
  

Raw content of original issue

Would it make sense to have support for optionally have the value bound by usernameColonPassword base64 encoded?


The scenario is that I'd like to have ONE Username and password credential defined in my Jenkins instance, representing the (user) account in Nexus. I'd like to be able to use that for all access with NExus, e.g. Maven repos and npm registries.

When publishing to a npm registry in Nexus it is possible to use basic auth and hence this username/password credential, but it needs to be base64 encoded. Info here: https://help.sonatype.com/repomanager3/formats/npm-registry#NpmRegistry-AuthenticationUsingBasicAuth


My idea is to add an additional optional param for usernameColonPassword to be able to specify that the value should be base64 encoded before bound. Possibly it could generalized to support different encodings, should it make sense.

• environment: n/a