Ir al contenido principal

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.

git can store the passwords by itself, but more interestingly it can delegate the password management in third-party utilities.

Specifically in the case of git running on MacOS, credential management usually relies on osxkeychain*, an utility that stores the repository domain and credentials in the builtin password management system: Keychain.

So every time git is asked to perform an operation on a given repository, it will ask osxkeychain to obtain the credentials for that repository domain. If found it will use them, and if not it will prompt the username and password (usually the first time the user access a repository in a git server).

So let's say you start working with a new git server, as for instance bitbucket.org, and you try to clone by the very first time a repository by running the command "git clone https://bitbucket.org/my-company/my-repo".

git will ask osxkeychain to get the credentials used for the server https://bitbucket.org. As Keychain doesn't contain those credentials yet, git will prompt the user for a username and a password and will ask osxkeychain to store them in Keychain.

Once stored, git will be able to retrieve them from Keychain every time an operation on https://bitbucket.org was performed, and so it will not ask for them again.

The credentials will be available by opening the Keychain app and then searching for entries containing the string "bitbucket.org". And "available" will mean that they will be not only readable but also editable, so in case of changing them in the Git server (in this case bitbucket.org), it will be possible to update them locally via Keychain.

Specifically for the case of Bitbucket deprecating the Atlasian account password credentials in favor of app credentials (something to happen on March 1st 2022), it will simply be necessary generating an app password as described here and then manually replacing the password stored in Keychain (deprecated account password) with the newly generated one (app password).

(*) To verify what third-party utility git uses for managing credentials, run the command "git config credential.helper".

Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what  linting  is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld {      using System;      public class Program      {           public static void Main(string[] args)           {                Console
Publicar un comentario
Leer más

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define
Publicar un comentario
Leer más