日本語 ▾ トピック ▾ 最新バージョン ▾ git-credential は 2.46.0 で最終更新されました

名前

git-credential - ユーザー認証情報の取得と保存

概要

'git credential' (fill|approve|reject|capability)

説明

Git には、システム固有のヘルパーから認証情報を保存および取得したり、ユーザーにユーザー名とパスワードを要求したりするための内部インターフェイスがあります。git-credential コマンドは、Git と同じ方法で認証情報を取得、保存、または要求したいスクリプトにこのインターフェイスを公開します。このスクリプト可能なインターフェイスの設計は、内部 C API をモデルにしています。概念の詳細については、credential.h を参照してください。

git-credential はコマンドラインで「アクション」オプション（fill、approve、または reject のいずれか）を受け取り、標準入力で認証情報の記述を読み取ります（入力/出力形式を参照）。

アクションが fill の場合、git-credential は設定ファイルを読み取ったり、設定されている認証情報ヘルパーに接続したり、ユーザーにプロンプトを表示したりすることで、記述に「username」と「password」属性を追加しようとします。その後、認証情報の記述のユーザー名とパスワード属性は、既に提供されている属性とともに標準出力に出力されます。

アクションが approve の場合、git-credential は記述を設定されている認証情報ヘルパーに送信し、ヘルパーは後で利用するために認証情報を保存する可能性があります。

アクションが reject の場合、git-credential は記述を設定されている認証情報ヘルパーに送信し、ヘルパーは記述に一致する保存済みの認証情報を消去する可能性があります。

アクションが capability の場合、git-credential はサポートしている機能を標準出力にアナウンスします。

アクションが approve または reject の場合、出力は発生しません。

GIT CREDENTIAL の一般的な使用法

git-credential を使用するアプリケーションは、通常、以下の手順で git credential を使用します。

  1. コンテキストに基づいて認証情報記述を生成します。

    たとえば、https://example.com/foo.git のパスワードが必要な場合、次のような認証情報記述を生成する可能性があります（末尾の空白行を忘れないでください。これは、アプリケーションがすべての情報の入力を完了したことを git credential に伝えます）

    protocol=https
host=example.com
path=foo.git

  2. git-credential に、この記述に対するユーザー名とパスワードを要求します。これは、git credential fill を実行し、手順 (1) の記述を標準入力にフィードすることで行われます。完全な認証情報記述（認証情報自体、つまりログインとパスワードを含む）は、次のように標準出力で生成されます。

    protocol=https
host=example.com
username=bob
password=secr3t

    ほとんどの場合、これは入力で与えられた属性が出力で繰り返されることを意味しますが、Git は認証情報記述を変更する可能性もあります。たとえば、プロトコルが HTTP(s) で credential.useHttpPath が false の場合、path 属性を削除する場合があります。

    git credential がパスワードを知っていた場合、この手順では、password=secr3t を返す前に、ユーザーが実際にこのパスワードを入力する必要がない可能性があります（代わりに、ユーザーはキーチェーンのロックを解除するためにパスワードを入力したか、キーチェーンが既にロック解除されている場合はユーザー操作は行われませんでした）。

  3. 認証情報を使用し（例：手順 (2) のユーザー名とパスワードで URL にアクセスし）、それが受け入れられるかどうかを確認します。

  4. パスワードの成功または失敗を報告します。認証情報によって操作が正常に完了できた場合、「approve」アクションでマークして、git credential に次の呼び出しで再利用するように伝えます。認証情報が操作中に拒否された場合、「reject」アクションを使用して、git credential が次の呼び出しで新しいパスワードを要求するようにします。いずれの場合も、git credential には、手順 (2) で取得した認証情報記述（手順 (1) で提供されたフィールドも含む）がフィードされるべきです。

入力/出力形式

git credential は、標準入力/出力で（使用されるアクションに応じて）認証情報情報を読み取り/書き込みます。この情報には、git credential がログイン情報を取得するキー（例：ホスト、プロトコル、パス）または取得する実際の認証情報データ（ユーザー名/パスワード）のいずれかに対応できます。

認証情報は、名前付き属性のセットに分割され、1 行に 1 つの属性があります。各属性は、= (イコール) 記号で区切られたキーと値のペアで指定され、その後に改行が続きます。

キーには、=、改行、または NUL 以外の任意のバイトを含めることができます。値には、改行または NUL 以外の任意のバイトを含めることができます。実装が効率的に解析できるように、末尾の改行を含む行は 65535 バイトを超えることはできません。

C スタイルの角括弧 [] で終わるキーを持つ属性は、複数の値を持つことができます。多値属性の各インスタンスは、値の順序付けられたリストを形成します。繰り返される属性の順序は、値の順序を定義します。空の多値属性（key[]=\n）は、以前のエントリをクリアし、リストをリセットする役割を果たします。

すべての場合において、すべてのバイトはそのまま扱われます（つまり、クォートはなく、改行または NUL を含む値を送信することはできません）。属性のリストは、空白行またはファイルの終わりで終了します。

Git は以下の属性を認識します。

protocol

認証情報が使用されるプロトコル (例: https)。

host

ネットワーク認証情報のリモートホスト名。ポート番号が指定されている場合はポート番号も含まれます (例: "example.com:8088")。

path

認証情報が使用されるパス。例として、リモートの HTTPS リポジトリにアクセスする場合、これはサーバー上のリポジトリのパスになります。

username

認証情報のユーザー名。既に持っている場合（例: URL、設定、ユーザー、または以前に実行されたヘルパーから）。

password

認証情報のパスワード (保存を要求している場合)。

password_expiry_utc

OAuth アクセストークンなどの生成されたパスワードには有効期限がある場合があります。ヘルパーから認証情報を読み取る際、git credential fill は期限切れのパスワードを無視します。Unix 時間 UTC、1970年からの秒数で表されます。

oauth_refresh_token

OAuth アクセストークンであるパスワードには、OAuth リフレッシュトークンが付随する場合があります。ヘルパーは、この属性をパスワード属性と同様に機密情報として扱う必要があります。Git 自体は、この属性に対して特別な動作はありません。

url

この特別な属性が git credential によって読み取られると、その値は URL として解析され、その構成要素が読み取られたかのように扱われます（例：url=https://example.com は、protocol=https と host=example.com が提供されたかのように動作します）。これは、呼び出し元が URL を自分で解析する手間を省くのに役立ちます。

プロトコルの指定は必須であり、URL がホスト名（例：「cert:///path/to/file」）を指定しない場合、認証情報には値が空の文字列であるホスト名属性が含まれることに注意してください。

URL に存在しないコンポーネント（例：上記の例にユーザー名がない）は未設定のままになります。

authtype

これは、対象の認証スキームを使用する必要があることを示します。HTTP および HTTPS の一般的な値には、basic、bearer、および digest がありますが、後者は安全でないため使用すべきではありません。credential が使用される場合、これは対象のプロトコル（通常は HTTP）に適した任意の文字列に設定できます。

この値は、入力に適切な機能 (下記参照) が提供されていない限り、送信すべきではありません。

credential

対象のプロトコル（通常は HTTP）に適した、事前にエンコードされた認証情報。このキーが送信される場合、authtype は必須であり、username と password は使用されません。HTTP の場合、Git は authtype の値とこの値をスペースで連結して Authorization ヘッダーを決定します。

この値は、入力に適切な機能 (下記参照) が提供されていない限り、送信すべきではありません。

ephemeral

このブール値は、真の場合、credential フィールドの値は有用性が時間的に限定されているため、認証情報ヘルパーによって保存されるべきではないことを示します。例えば、HTTP Digest の credential 値はノンスを使用して計算され、再利用しても認証は成功しません。これは、短期間（例：24時間）の認証情報の場合にも使用されることがあります。デフォルト値は false です。

認証情報ヘルパーは、操作が成功したかどうかを判断するために、引き続き store または erase と共に呼び出されます。

この値は、入力に適切な機能 (下記参照) が提供されていない限り、送信すべきではありません。

state[]

この値は、このヘルパーが再度呼び出された場合に、このヘルパーに返される不透明な状態を提供します。各異なる認証情報ヘルパーは、これを一度指定できます。値には、認証情報ヘルパーに固有のプレフィックスを含める必要があり、そのプレフィックスに一致しない値は無視する必要があります。

この値は、入力に適切な機能 (下記参照) が提供されていない限り、送信すべきではありません。

continue

これはブール値で、有効な場合、この認証が多段階認証ステップの最終ではない部分であることを示します。これは、NTLM や Kerberos などのプロトコルで一般的であり、2 ラウンドのクライアント認証が必要な場合、このフラグを設定することで、認証情報ヘルパーが多段階認証ステップを実装できます。このフラグは、次の段階が必要な場合にのみ送信されるべきです。つまり、次の認証ラウンドが期待される場合です。

この値は、入力に適切な機能 (下記参照) が提供されていない限り、送信すべきではありません。この属性は、認証情報ヘルパーから Git (または git credential を呼び出す他のプログラム) へ情報を渡すための一方向です。

wwwauth[]

Git が 1 つ以上の WWW-Authenticate 認証ヘッダーを含む HTTP レスポンスを受け取ると、これらは Git によって認証情報ヘルパーに渡されます。

各 WWW-Authenticate ヘッダー値は、多値属性 wwwauth[] として渡され、属性の順序は HTTP レスポンスに表示される順序と同じです。この属性は、Git から認証情報ヘルパーに追加情報を渡すための一方向です。

capability[]

これは、Git、または適切な場合、ヘルパーが対象の機能をサポートしていることを示します。これは、プロトコルの一部として、より優れた、より具体的なデータを提供するために使用できます。capability[] ディレクティブは、それに依存する値の前に置かれなければならず、これらのディレクティブはプロトコルでアナウンスされる最初の項目であるべきです。

現在サポートされている機能は2つあります。1つ目は authtype で、これは authtype、credential、および ephemeral の値が理解されていることを示します。2つ目は state で、これは state[] および continue の値が理解されていることを示します。

機能がサポートされているからといって、追加機能を使用する義務はありませんが、機能なしで提供すべきではありません。

認識されない属性と機能は、黙って破棄されます。

機能の入出力形式

git credential capability の場合、形式は少し異なります。まず、プロトコルの現在のバージョンを示すために version 0 のアナウンスが行われ、次に各機能が capability authtype のような行でアナウンスされます。認証情報ヘルパーもこの形式を実装することができ、その場合も capability 引数を伴います。将来的には追加の行が追加される可能性があります。呼び出し元は、理解できない行を無視すべきです。

これは認証情報ヘルパープロトコルの新しい部分であるため、古いバージョンの Git や一部の認証情報ヘルパーはこれをサポートしていない可能性があります。ゼロ以外の終了ステータスが返された場合、または最初の行が単語 version とスペースで始まらない場合、呼び出し元は機能がサポートされていないと仮定すべきです。

この形式の意図は、認証情報出力と明確に区別することです。常に同じ出力を生成する非常に単純な認証情報ヘルパー（インラインシェルスクリプトなど）を使用することは可能です。異なる形式を使用することで、ユーザーは機能の広告を正しく実装したり、機能を問い合わせる呼び出し元を誤って混乱させたりすることを心配せずに、この構文を使い続けることができます。

GIT

git[1]スイートの一部

scroll-to-top