Нужно ли хранить токен локального доступа где-то локально на машине после его создания в GitHub?
Если да, есть ли какой-либо предпочтительный способ его хранения?
Нужно ли хранить токен локального доступа где-то локально на машине после его создания в GitHub?
Если да, есть ли какой-либо предпочтительный способ его хранения?
Половина паролей - это то, что (в идеале) вы их запоминаете, а система хэширует их, поэтому они никогда не хранятся в текстовом формате.
Тем не менее, система доступа к персональному доступу GitHub, похоже, в основном заставляет вас хранить токен в виде обычного текста?
Во-первых, PAT (Personal Access Token) - это не простой пароль, а эквивалент, который:
Это отличается от вашего пароля, который уникален для вашей учетной записи и не может быть легко изменен без необходимости изменять его, а также везде, где вы его используете.
Поскольку PAT можно использовать вместо пароля при выполнении операций Git через HTTPS с Git в командной строке или API, вы можете использовать помощник учетных данных git для безопасного кэширования.
Например, в Windows, который будет использовать диспетчер учетных данных Windows, доступ через GCM-Git Credential Manager для Windows.
git config --global credential.helper manager
При первом нажатии на репо всплывающее окно запрашивает ваши учетные данные: имя пользователя и ваш PAT.
В следующий раз он не будет запрашивать и повторно использовать PAT, который будет храниться безопасно в вашем диспетчере учетных данных.
Аналогичная идея применима к Mac с брелками OSX, а Linux - к GNOME Keyring.
Идея остается: хранить PAT в зашифрованном хранилище учетных данных.
Ну, вы должны где-то сохранить токен, когда вы не хотите вводить его каждый раз, когда ваше приложение запрашивает его: -)
Хорошим решением является использование переменных среды, как уже было предложено в одном комментарии.
Но вы все равно должны установить переменную окружения где-нибудь.
В Windows (который я использую) вы можете использовать диалоговое окно в системных настройках (я не знаю, есть ли у других операционных систем что-то подобное).
Я не делаю этого, я предпочитаю script в своем проекте.
В частном проекте вы можете передать это правилу источника, но это зависит от предпочтения.
В одном из моих личных проектов я также называю API GitHub, используя токен доступа. Это приложение командной строки, и конечный пользователь сохранит токен в файле конфигурации (это нормально).
Но мне нужен токен для разработки, потому что у проекта есть интеграционные тесты, где я называю API GitHub.
И этот проект является общедоступным в GitHub, поэтому я не смог сохранить токен в исходном элементе управления.
Я сделал следующее:
environment-variables.bat
, который устанавливает все необходимые переменные среды, включая токен доступаenvironment-variables.bat
игнорируется в исходном управленииenvironment-variables.bat.sample
вместо этого, который содержит то же самое, но поддельный токен/пароль.Поэтому я могу просто переименовать этот файл в environment-variables.bat
, заменить поддельный пароль на реальный, и все будет работать.
Это не идеальное решение для всех случаев.
В моем проекте у меня есть проблема, что в будущем мне нужно будет использовать больше токенов/паролей для большего количества API.
Таким образом, количество токенов в моем environment-variables.bat
будет увеличиваться, что затрудняет потенциальным вкладчикам фактически выполнять все интеграционные тесты. И я еще не знаю, как с этим бороться.
В основном я сделал это на своей машине:
https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23
Скрипт моего профиля немного отличается от описанного:
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
Мне нравится держать их зашифрованными в репозитории и загружать их с помощью .envrc
(https://direnv.net/)
Для этого я использую ssh-vault для шифрования данных, используя мои ssh-ключи, которые GitHub уже разоблачает, например:
echo MY_TOKEN="secret" | ssh-vault -u <github-user> create > my-encypted-vars.ssh
Тогда содержимое .envrc
выглядит примерно так:
echo "Enter ssh key password"
context=$(ssh-vault view $HOME/projects/my-encrypted.ssh | tail -n +2)
export ${context}
Это позволит расшифровать данные в my-encrypted-vars.ssh
файл и установить MY_TOKEN
в моих переменных окружения каждый раз, когда я cd
в реж проекта.
Делая это, токены/переменные хранятся "безопасно" и всегда готовы к использованию в качестве переменных среды