Где хранить персональный токен доступа из GitHub?

необходимо ли хранить маркер личного доступа где-то локально на машине после его генерации в GitHub?

Если да, есть ли способ, где он может храниться?

18
access-token git github

4 ответов

половина смысла паролей заключается в том, что (в идеале) вы запоминаете их, и система хэширует их, поэтому они никогда не хранятся нигде в обычном тексте.
Тем не менее, личная система токенов доступа GitHub, похоже, в основном заставляет вас хранить токен в обычном тексте?

во-первых, a PAT (персональный токен доступа) - это не простой пароль, а эквивалент, который:

  • вы можете генерировать несколько раз (например, один на машина, с которой вам нужно получить доступ к репозиторию GitHub)
  • вы можете отменить в любое время (из веб-интерфейса GitHub), что делает этот ПЭТ устаревшим, даже если он задерживается на одной из этих машин.

это отличается от вашего пароля, который уникален для вашей учетной записи и не может быть легко изменен без необходимости его изменения, а также везде, где вы его используете.

Так как ПЭТ может использоваться вместо пароль при выполнении операций Git через HTTPS с Git в командной строке или API вы можете использовать git credential helper надежно кэшировать.
Например, в Windows это будет использовать диспетчер учетных данных Windows доступ через GCM -- Git менеджер учетных данных -- для Windows.

git config --global credential.helper manager

при первом нажатии на репо всплывающее окно запросит ваши учетные данные: username и ваш ПОХЛОПЫВАНИЕ.
В следующий раз он не будет спрашивать и повторно использовать непосредственно этот PAT, который остается надежно сохраненным в Вашем менеджере учетных данных.

аналогичная идея применяется для Mac с OSX брелок, и Linux с брелок GNOME.
Идея остается: хранить PAT в зашифрованные хранилище учетных данных.

4

Ну, вы должны сохранить маркер где-то, когда вы не хотите вводить его каждый раз, когда приложение попросит об этом :-)

хорошим решением является использование переменных среды, как уже отмечалось в комментарий.

но вы все равно должны установить переменную окружения где-то.
В Windows (которую я использую) вы можете использовать поле в настройках системы (Я не знаю, есть ли другие операционные системы что-то похожее).

я этого не делаю, я предпочитаю сценарий в своем проекте.
В частном проекте вы мая зафиксируйте это в системе управления версиями, но это вопрос предпочтения.

в одном из моих личных проектов я также вызываю API GitHub, используя личный токен доступа.
Это приложение командной строки, и конечный пользователь сохранит токен в файле конфигурации (что нормально).

но мне нужен маркер для разработка также, потому что в проекте есть интеграционные тесты, где я вызываю API GitHub.

и этот проект является общедоступным на GitHub, поэтому я не смог сохранить токен в системе управления версиями.

вот что я сделал:

поэтому я могу просто переименовать этот файл в environment-variables.bat заменить поддельные пароль, и все работает.

Это не идеальное решение для всех случаев, хотя.

в моем проекте у меня есть проблема, что мне нужно использовать больше токенов/паролей для большего количества API в будущем.

Итак, количество токенов в my environment-variables.bat будет увеличение, что затрудняет потенциальным участникам фактическое выполнение всех интеграционных тестов. И я все еще не знаю, как с этим бороться?.

1

в основном я сделал это на моей машине:

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
1

мне нравится хранить их в зашифрованном виде в репозитории и загружать их с помощью .envrc (https://direnv.net/)

для этого я использую ssh-vault для шифрования данных с помощью my 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}

это расшифрует данные в и set MY_TOKEN в моем окружении переменные каждый раз, когда я cd в проект реж.

делая это, токены / переменные хранятся "безопасно" и всегда готовы к использованию в качестве переменных среды

1