@@ -6,8 +6,52 @@ password credentials from the user (even though credentials in the wider
6
6
world can take many forms, in this document the word "credential" always
7
7
refers to a username and password pair).
8
8
9
+ This document describes two interfaces: the C API that the credential
10
+ subsystem provides to the rest of git, and the protocol that git uses to
11
+ communicate with system-specific "credential helpers". If you are
12
+ writing git code that wants to look up or prompt for credentials, see
13
+ the section "C API" below. If you want to write your own helper, see
14
+ the section on "Credential Helpers" below.
15
+
16
+ Typical setup
17
+ -------------
18
+
19
+ ------------
20
+ +-----------------------+
21
+ | git code (C) |--- to server requiring --->
22
+ | | authentication
23
+ |.......................|
24
+ | C credential API |--- prompt ---> User
25
+ +-----------------------+
26
+ ^ |
27
+ | pipe |
28
+ | v
29
+ +-----------------------+
30
+ | git credential helper |
31
+ +-----------------------+
32
+ ------------
33
+
34
+ The git code (typically a remote-helper) will call the C API to obtain
35
+ credential data like a login/password pair (credential_fill). The
36
+ API will itself call a remote helper (e.g. "git credential-cache" or
37
+ "git credential-store") that may retrieve credential data from a
38
+ store. If the credential helper cannot find the information, the C API
39
+ will prompt the user. Then, the caller of the API takes care of
40
+ contacting the server, and does the actual authentication.
41
+
42
+ C API
43
+ -----
44
+
45
+ The credential C API is meant to be called by git code which needs to
46
+ acquire or store a credential. It is centered around an object
47
+ representing a single credential and provides three basic operations:
48
+ fill (acquire credentials by calling helpers and/or prompting the user),
49
+ approve (mark a credential as successfully used so that it can be stored
50
+ for later use), and reject (mark a credential as unsuccessful so that it
51
+ can be erased from any persistent storage).
52
+
9
53
Data Structures
10
- ---------------
54
+ ~~~~~~~~~~~~~~~
11
55
12
56
`struct credential`::
13
57
@@ -28,7 +72,7 @@ This struct should always be initialized with `CREDENTIAL_INIT` or
28
72
29
73
30
74
Functions
31
- ---------
75
+ ~~~~~~~~~
32
76
33
77
`credential_init`::
34
78
@@ -72,7 +116,7 @@ Functions
72
116
Parse a URL into broken-down credential fields.
73
117
74
118
Example
75
- -------
119
+ ~~~~~~~
76
120
77
121
The example below shows how the functions of the credential API could be
78
122
used to login to a fictitious "foo" service on a remote host:
@@ -135,8 +179,10 @@ credentials from and to long-term storage (where "long-term" is simply
135
179
longer than a single git process; e.g., credentials may be stored
136
180
in-memory for a few minutes, or indefinitely on disk).
137
181
138
- Each helper is specified by a single string. The string is transformed
139
- by git into a command to be executed using these rules:
182
+ Each helper is specified by a single string in the configuration
183
+ variable `credential.helper` (and others, see linkgit:../git-config[1]).
184
+ The string is transformed by git into a command to be executed using
185
+ these rules:
140
186
141
187
1. If the helper string begins with "!", it is considered a shell
142
188
snippet, and everything after the "!" becomes the command.
@@ -243,3 +289,10 @@ request.
243
289
If a helper receives any other operation, it should silently ignore the
244
290
request. This leaves room for future operations to be added (older
245
291
helpers will just ignore the new requests).
292
+
293
+ See also
294
+ --------
295
+
296
+ linkgit:../gitcredentials[7]
297
+
298
+ linkgit:../git-config[5] (See configuration variables `credential.*`)
0 commit comments