Git - сховище облікових даних

Сховище облікових даних

Якщо для підключення до віддалених серверів ви використовуєте SSH-транспорт, то ви можете використовувати ключ без пароля, що дозволить вам безпечно передавати дані без введення логіна і пароля. Однак, це неможливо при використанні HTTP-протоколів - кожне підключення вимагає пари логін, пароль. Все ще складніше для систем з двухфакторной аутентификацией, коли вираз, яке ви використовуєте в якості пароля, генерується випадково і його складно відтворити.

На щастя, в Git є система управління обліковими даними, яка може допомогти в цьому. У Git "з коробки" є кілька опцій:

За замовчуванням Git НЕ кешує облікові дані зовсім. Кожне підключення буде запитувати у вас логін і пароль.

У режимі "cache" облікові дані зберігаються в пам'яті протягом певного періоду часу. Жоден з паролів ніколи не зберігається на диск і всі вони видаляються з кеша через 15 хвилин.

У режимі "store" облікові дані зберігаються на необмежений час у відкритому вигляді у файлі на диску. Це означає що, до тих пір поки ви не зміните пароль до Git-сервера, вам не буде потрібно більше вводити ваші облікові дані. Недоліком такого підходу є те, що ваш пароль зберігається у відкритому вигляді у файлі в вашому домашньому каталозі.

Ми можете вибрати один з цих методів, змінивши вигляд Git:

Деякі з цих помічників мають опції. Помічник "store" може приймати аргумент --file . який визначає де буде зберігається файл з відкритими обліковими даний (за замовчуванням використовується

/.git-credentials). Помічник "cache" приймає опцію --timeout . яка змінює проміжок часу, протягом якого демон залишається запущеним (за замовчуванням "900", або 15 хвилин). Нижче наведено приклад як ви можете налаштувати помічник "store" на використання певного файлу:

Git дозволяє налаштовувати відразу кілька помічників. При пошуку облікових даних для конкретного сервера, Git буде по порядку запитувати у них облікові дані і зупиниться при отриманні першої відповіді. При збереженні облікових даних, Git відправить їх усім помічникам в списку, які вже в свою чергу можуть вирішити, що з цими даними робити. Нижче наведено як буде виглядати .gitconfig. якщо у вас є файл з обліковими даними на флеш-диску, але, на випадок його відсутності, ви хочете додатково використовувати кешування в оперативній пам'яті.

Під капотом

Це команда, яка починає взаємодію.

Після цього Git-credential очікує дані зі стандартного потоку введення. Ми передаємо йому те, що знаємо: протокол і ім'я сервера.

Порожній рядок позначає, що введення закінчений і система управління обліковими даними повинна відповісти, що їй відомо.

Після цього Git-credential виконує якусь роботу і виводить виявлену інформацію.

Якщо облікові дані не знайдені, Git запитує у користувача логін / пароль, і виводить їх назад до задіяного потік виводу (в даному прикладі це одна і та ж консоль).

Насправді, система управління обліковими даними викликає програми, відокремлені від самого Git; які і як залежить в тому числі і від налаштувань credential.helper. Існує кілька варіантів виклику:

Отже, помічники, описані вище насправді називаються 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 повертає логін і пароль, які ми зберегли раніше.

Нижче наведено вміст файлу

Це просто набір рядків, кожна з яких містить URL, що включає в себе облікові дані. Помічники osxkeychain і winstore використовують формати, що лежать в основі їх сховищ, а cache використовує його власний формат зберігання у внутрішній пам'яті (який інші процеси прочитати не можуть).

Власне сховище облікових даних

Ми повинні приділити увагу тільки одній операції get; store і erase є операціями запису, тому ми не будемо нічого робити при їх отриманні.

Формат файлу з спільно використовуваними обліковими даними такий же як і у git-credential-store.

Розташування це файлу більш-менш стандартний, але, про всяк випадок, ми повинні дозволяти користувачам передавати свій власний шлях.

Тут ми розбираємо аргументи командного рядка, дозволяючи вказувати користувачам вхідний файл. За замовчуванням це

Ця програма відповідає тільки якщо операцією є get і файл сховища існує.

Цей цикл читає вміст файлу сховища, виконуючи пошук відповідності. Якщо протокол і сервер з known відповідають поточному рядку, програма виводить результат і завершує роботу.

Ми збережемо нашого помічника як git-credential-read-only. розташуємо його в одній з директорій з PATH і зробимо його виконуваним. Нижче наведено на що буде схожий сеанс взаємодії:

Так як його ім'я починається з "git-", ми можемо використовувати простий синтаксис для настройки:

Як ви бачите, розширювати цю систему досить просто і це дозволяє вирішити деякі загальні проблеми, які можуть виникнути у вас і вашої команди.

Схожі статті