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

Ответ 1

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

Во-первых, PAT (Personal Access Token) - это не простой пароль, а эквивалент, который:

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

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

Поскольку 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 в зашифрованном хранилище учетных данных.

Ответ 2

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

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

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

Я не делаю этого, я предпочитаю script в своем проекте.
В частном проекте вы можете передать это правилу источника, но это зависит от предпочтения.

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

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

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

Я сделал следующее:

• У меня есть пакетный файл (помните, я нахожусь в Windows) под названием environment-variables.bat, который устанавливает все необходимые переменные среды, включая токен доступа
• Я называю это в build script и в пакетный файл Я использую для запуска своих тестов
• environment-variables.bat игнорируется в исходном управлении
• Но в контроле источника там environment-variables.bat.sample вместо этого, который содержит то же самое, но поддельный токен/пароль.

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

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

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

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

Ответ 3

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

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

Ответ 4

Мне нравится держать их зашифрованными в репозитории и загружать их с помощью .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 в реж проекта.

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