git 在哪里存储来自 GitHub 的个人访问令牌？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/46645843/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Where to store the personal access token from GitHub?
提问by Krzysztof S?owiński
Is it necessary to store the personal access token somewhere locally on the machine after generating it in GitHub?
在 GitHub 中生成个人访问令牌后，是否需要将其存储在机器本地的某个位置？
If yes, is there any preferred way where it could be stored?
如果是，是否有任何首选方式可以存储它？
采纳答案by VonC
Half the point of passwords is that (ideally) you memorize them and the system hashes them, so therefore they're never stored anywhere in plain text.
Yet GitHub's personal access token system seems to basically force you to store the token in plain text?
密码的一半在于（理想情况下）您记住它们并且系统对它们进行哈希处理，因此它们永远不会以纯文本形式存储在任何地方。
然而 GitHub 的个人访问令牌系统似乎基本上强迫你以纯文本形式存储令牌？
First, a PAT (Personal Access Token)is not a simple password, but an equivalent that:
首先，PAT（个人访问令牌）不是简单的密码，而是等效的：
- you can generate multiple time (for instance, one per machine from which you need to access GitHub repository)
- you can revokeat any time (from the GitHub web interface), which makes that PAT obsolete, even if it lingers around on one of those machines.
- 您可以多次生成（例如，每台需要访问 GitHub 存储库的机器生成一个）
- 您可以随时撤销（从 GitHub 网络界面），这使得 PAT 过时，即使它在其中一台机器上徘徊。
That differs from your password, which is unique to your account, and cannot be easily changed without having to alsomodify it everywhere you happen to use it.
这不同于您的密码，这是唯一的帐户，不能不必轻易改变还修改它无处不在，你碰巧使用它。
Since a PAT can be used in place of a password when performing Git operations over HTTPS with Git on the command line or the API, you can use a git credential helperto cache it securely.
On Windows, for instance, that would use the Windows Credential Manager, through the GCM -- Git Credential Manager -- for Windows:
由于在命令行或 API 上使用 Git 通过 HTTPS 执行 Git 操作时，可以使用 PAT 代替密码，因此您可以使用git 凭据助手来安全地缓存它。
例如，在 Windows 上，这将使用Windows Credential Manager，通过GCM -- Git Credential Manager -- for Windows：
git config --global credential.helper manager
The first time you are pushing to a repo, a popup will ask for your credentials: username andyour PAT.
The next time, it won't ask, and reuse directly that PAT, which remains stored securely in your Credential Manager.
第一次推送到仓库时，弹出窗口会询问您的凭据：用户名和PAT。
下一次，它不会询问并直接重用该 PAT，该 PAT 仍然安全地存储在您的凭据管理器中。
A similar idea applies for Mac with the OSX keychain, and Linux with the GNOME Keyring.
The idea remains: store the PAT in an encryptedcredentials store.
类似的想法适用于带有 OSX 钥匙串的 Mac和带有GNOME 钥匙环的Linux 。
这个想法仍然存在：将 PAT 存储在加密的凭证存储中。
回答by nbari
I like to keep them encrypted within the repository and load them using .envrc(https://direnv.net/)
我喜欢将它们加密在存储库中并使用.envrc( https://direnv.net/)加载它们
For doing this I use ssh-vaultto encrypt the data using my ssh keys that GitHub already is exposing, for example:
为此，我使用ssh-vault使用GitHub 已经公开的 ssh 密钥来加密数据，例如：
echo MY_TOKEN="secret" | ssh-vault -u <github-user> create > my-encypted-vars.ssh
Then the content of .envrclooks something like this:
然后内容.envrc看起来像这样：
echo "Enter ssh key password"
context=$(ssh-vault view $HOME/projects/my-encrypted.ssh | tail -n +2)
export ${context}
This will decrypt the data in my-encrypted-vars.sshfile and set MY_TOKENinto my environment variables every time I cdinto the project dir.
每次我进入项目目录时，这都会解密my-encrypted-vars.ssh文件中的数据并设置MY_TOKEN到我的环境变量中cd。
By doing this tokens/variables are stored "safely" and always ready to use as environment variables
通过这样做，令牌/变量被“安全地”存储并随时准备用作环境变量
回答by Christian Specht
Well, you have to save the token somewhere, when you don't want to type it each time your app asks for it :-)
好吧，您必须将令牌保存在某处，当您不想在每次应用程序要求时都输入它时 :-)
A good solution is using environment variables, as already suggested in one comment.
一个好的解决方案是使用环境变量，正如在一条评论中已经建议的那样。
But you still have to set the environment variable somewhere.
On Windows (which I'm using), you could use the dialog box in the system settings (I don't know if other operating systems have something similar).
但是您仍然必须在某处设置环境变量。
在Windows（我正在使用）上，您可以使用系统设置中的对话框（我不知道其他操作系统是否有类似的东西）。
I don't do this, I prefer a script in my project.
In a private project, you maycommit this to source control, but this is a matter of preference.
我不这样做，我更喜欢我的项目中的脚本。
在私人项目中，您可以将其提交给源代码管理，但这是一个偏好问题。
In one of my personal projects, I'm calling the GitHub API as well, using a personal access token.
It's a command line app and the end user will save the token in a config file (which is OK).
在我的一个个人项目中，我也使用个人访问令牌调用 GitHub API。
这是一个命令行应用程序，最终用户将把令牌保存在一个配置文件中（没问题）。
But I need the token for development as well, because the project has integration tests where I'm calling the GitHub API.
但我也需要用于开发的令牌，因为该项目有集成测试，我在其中调用了 GitHub API。
And that project is public on GitHub, so I couldn't save the token in source control.
该项目在 GitHub 上是公开的，因此我无法将令牌保存在源代码管理中。
What I did is this:
我所做的是这样的：
- I have a batch file (remember, I'm on Windows)called
environment-variables.batwhich sets all required environment variables including the access token - I'm calling this in my build scriptand in the batch fileI'm using to run my tests
environment-variables.batis ignored in source control- But in source control, there's
environment-variables.bat.sampleinstead, which contains the same, but a fake token/password.
- 我有一个批处理文件（记得，我是在Windows上）称为
environment-variables.bat其将所有所需的环境变量，包括访问令牌 - 我在我的构建脚本和我用来运行我的测试的批处理文件中调用它
environment-variables.bat在源代码管理中被忽略- 但在源代码管理中，有
environment-variables.bat.sample一个包含相同但假令牌/密码的替代方法。
So I can just rename this file to environment-variables.bat, replace the fake password by the real one, and everything works.
所以我可以将此文件重命名为environment-variables.bat，用真实密码替换假密码，一切正常。
This is not the perfect solution for all cases, though.
但是，这并不是所有情况的完美解决方案。
In my project, I have the problem that I need to use more tokens/passwords for more APIs in the future.
在我的项目中，我遇到了一个问题，我需要在未来为更多的 API 使用更多的令牌/密码。
So the number of tokens in my environment-variables.batwillincrease, making it difficult for potential contributors to actually execute all integration tests. And I still don't know how to deal with that.
因此我environment-variables.bat遗嘱中的代币数量增加，使得潜在贡献者难以实际执行所有集成测试。我仍然不知道如何处理。
回答by memo
Basically I did this on my machine:
基本上我在我的机器上做了这个：
https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23
https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23
My profile script is slightly different than described:
我的配置文件脚本与描述的略有不同：
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
