Password for 'https://bob@unknownhost':
protocol=https
host=unknownhost
username=bob
password=s3cre7
1. ①Это команда, которая начинает взаимодействие.
2. ②После этого Git-credential ожидает данные из стандартного потока ввода. Мы передаем ему то, что знаем: протокол и имя сервера.
3. ③Пустая строка обозначает, что ввод закончен и система управления учетными данными должна ответить, что ей известно.
4. ④После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию.
5. ⑤Если учетные данные не найдены, Git спрашивает у пользователя логин/пароль, и выводит их обратно в задействованный поток вывода (в данном примере это одна и та же консоль).
В действительности, система управления учетными данными вызывает программы, отделенные от самого Git; какие и как зависит в том числе и от настроек credential.helper. Существует несколько вариантов вызова:
Настройки |
Поведение |
foo |
Выполняется git-credential-foo |
foo -a --opt=bcd |
Выполняется git-credential-foo -a --opt=bcd |
/absolute/path/foo -xyz |
Выполняется /absolute/path/foo -xyz |
!f() { echo "password=s3cre7"; }; f |
Код после символа ! выполняется в шелле |
Итак, помощники, описанные выше на самом деле называются git-credential-cache, git-credential-store и т.д. и мы можем настроить их на прием аргументов командной строки. Общая форма для этого git-credential-foo [args] . Протокол ввода/вывода такой же как и у git-credential, но они используют немного другой набор операций:
● get запрос логина и пароля.
● store запрос на сохранение учетных данных в памяти помощника.
● erase удаляет учетные данные для заданных параметров из памяти используемого помощника.
Для операций store и erase не требуется ответа (в любом случае Git его игнорирует). Однако, для Git очень важно, что помощник ответит на операцию get. Если помощник не знает что-либо полезного, он может просто завершить работу не выводя ничего, но если знает – он должен добавить к введенной информации имеющуюся у него информацию. Вывод обрабатывается как набор операций присваивания; выведенные значения заменят те, что Git знал до этого.
Ниже приведет пример, используемый ранее, но вместо git-credential напрямую вызывается git-credential-store:
$git credential-store --file ~/git.store store ①
protocol=https
host=mygithost
username=bob
password=s3cre7
$git credential-store --file ~/git.store get ②
protocol=https
host=mygithost
username=bob ③
password=s3cre7
1. ①Здесь мы просим git-credential-store сохранить некоторые учетные данные: логин “bob” и пароль “s3cre7”, которые будут использоваться при доступе к https://mygithost.
2. ②Теперь мы извлечем эти учетные данные. Мы передаем часть уже известных нам параметров подключения (https://mygithost) и пустую строку.
3. ③git-credential-store возвращает логин и пароль, которые мы сохранили ранее.
Ниже приведено содержимое файла ~/git.store:
https://bob:s3cre7@mygithost
Это просто набор строк, каждая из которых содержит URL, включающий в себя учетные данные. Помощники osxkeychain и winstore используют форматы, лежащие в основе их хранилищ, а cache использует его собственный формат хранения во внутренней памяти (который другие процессы прочитать не могут).
Собственное хранилище учетных данных
Поскольку git-credential-store и подобные ей утилиты являются отдельными от Git программами, не сложно сделать так, чтобы любая программа могла быть помощником авторизации Git. Помощники предоставляемые Git покрывают наиболее распространенные варианты использования, но не все. Для примера допустим, что ваша команда имеет некоторые учетные данные, совместно используемые всей командой, например, для развертывания. Эти данные хранятся в общедоступной директории, но вы не хотите копировать их в ваше собственное хранилище учетных данных, так как они часто изменяются. Ни один из существующих помощников не покрывает этот случай; давайте посмотрим, что будет стоить написать свой собственный. Есть несколько ключевых особенностей, которым должна удовлетворять эта программа:
1. Мы должны уделить внимание только одной операции get; store и erase являются операциями записи, поэтому мы не будем ничего делать при их получении.
2. Формат файла с совместно используемыми учетными данными такой же как и у git-credential-store.
3. Расположение это файла более-менее стандартное, но, на всякий случай, мы должны позволять пользователям передавать свой собственный путь.
Мы снова напишем расширение на Ruby, но подойдет любой язык, так как Git может использовать всё, что сможет запустить на выполнение. Ниже приведен полный исходный код нашего нового помощника авторизации:
Читать дальше