Où stocker le jeton d'accès personnel de GitHub ?

Question

Est-il nécessaire de stocker le jeton d'accès personnel quelque part en local sur la machine après l'avoir généré dans GitHub ?

Dans l'affirmative, y a-t-il un moyen privilégié de le stocker ?

Answer 1

Eh bien, vous devez sauvegarder le jeton quelque part quand vous ne voulez pas le taper à chaque fois que votre application vous le demande :-)

Une bonne solution est l'utilisation de variables d'environnement, comme déjà suggéré dans un commentaire .

Mais vous devez toujours définir la variable d'environnement quelque part.
Sous Windows (que j'utilise), vous pouvez utiliser la commande boîte de dialogue dans les paramètres du système (Je ne sais pas si d'autres systèmes d'exploitation ont quelque chose de similaire) .

Je ne le fais pas, je préfère un script dans mon projet.
Dans un projet privé, vous mai commettre cette opération dans le contrôle de la source, mais c'est une question de préférence.

Dans l'un de mes projets personnels, j'appelle également l'API GitHub, en utilisant un jeton d'accès personnel.
Il s'agit d'une application en ligne de commande et l'utilisateur final enregistrera le jeton dans un fichier de configuration. (ce qui est bien) .

Mais j'ai également besoin du jeton pour le développement, car le projet comporte des tests d'intégration où j'appelle l'API GitHub.

Et ce projet est public sur GitHub, donc je ne pouvais pas enregistrer le jeton dans le contrôle de la source.

Ce que j'ai fait, c'est ça :

• J'ai un fichier batch (rappelez-vous, je suis sous Windows) appelé environment-variables.bat qui définit toutes les variables d'environnement requises, y compris le jeton d'accès
• J'appelle ça dans mon construire script et dans le fichier de lots que j'utilise pour exécuter mes tests
• environment-variables.bat est ignoré dans le contrôle de la source
• Mais dans le contrôle de la source, il y a environment-variables.bat.sample à la place, qui contient la même chose, mais un faux jeton/mot de passe.

Donc je peux juste renommer ce fichier en environment-variables.bat remplacez le faux mot de passe par le vrai, et tout fonctionne.

---

Ce n'est cependant pas la solution idéale pour tous les cas.

Dans mon projet, j'ai le problème suivant : je dois utiliser davantage de jetons/mots de passe pour d'autres API à l'avenir.

Donc le nombre de jetons dans mon environment-variables.bat sera augmentent, ce qui rend difficile pour les contributeurs potentiels l'exécution effective de tous les tests d'intégration. Et je continue je ne sais pas comment gérer ça .

Answer 2

En gros, j'ai fait ça sur ma machine :

https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23

Mon profil script est légèrement différent de celui décrit :

env=~/.ssh/agent.env

agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }

agent_start () {
    (umask 077; ssh-agent >| "$env")
        . "$env" >| /dev/null ; 
}

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
    ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
    ssh-add
fi

unset env