The requested URL was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
+ lzmJeAqţ |_I| #w credentials API =============== The credentials API provides an abstracted way of gathering username and password credentials from the user (even though credentials in the wider world can take many forms, in this document the word "credential" always refers to a username and password pair). This document describes two interfaces: the C API that the credential subsystem provides to the rest of Git, and the protocol that Git uses to communicate with system-specific "credential helpers". If you are writing Git code that wants to look up or prompt for credentials, see the section "C API" below. If you want to write your own helper, see the section on "Credential Helpers" below. Typical setup ------------- ------------ +-----------------------+ | Git code (C) |--- to server requiring ---> | | authentication |.......................| | C credential API |--- prompt ---> User +-----------------------+ ^ | | pipe | | v +-----------------------+ | Git credential helper | +-----------------------+ ------------ The Git code (typically a remote-helper) will call the C API to obtain credential data like a login/password pair (credential_fill). The API will itself call a remote helper (e.g. "git credential-cache" or "git credential-store") that may retrieve credential data from a store. If the credential helper cannot find the information, the C API will prompt the user. Then, the caller of the API takes care of contacting the server, and does the actual authentication. C API ----- The credential C API is meant to be called by Git code which needs to acquire or store a credential. It is centered around an object representing a single credential and provides three basic operations: fill (acquire credentials by calling helpers and/or prompting the user), approve (mark a credential as successfully used so that it can be stored for later use), and reject (mark a credential as unsuccessful so that it can be erased from any persistent storage). Data Structures ~~~~~~~~~~~~~~~ `struct credential`:: This struct represents a single username/password combination along with any associated context. All string fields should be heap-allocated (or NULL if they are not known or not applicable). The meaning of the individual context fields is the same as their counterparts in the helper protocol; see the section below for a description of each field. + The `helpers` member of the struct is a `string_list` of helpers. Each string specifies an external helper which will be run, in order, to either acquire or store credentials. See the section on credential helpers below. This list is filled-in by the API functions according to the corresponding configuration variables before consulting helpers, so there usually is no need for a caller to modify the helpers field at all. + This struct should always be initialized with `CREDENTIAL_INIT` or `credential_init`. Functions ~~~~~~~~~ `credential_init`:: Initialize a credential structure, setting all fields to empty. `credential_clear`:: Free any resources associated with the credential structure, returning it to a pristine initialized state. `credential_fill`:: Instruct the credential subsystem to fill the username and password fields of the passed credential struct by first consulting helpers, then asking the user. After this function returns, the username and password fields of the credential are guaranteed to be non-NULL. If an error occurs, the function will die(). `credential_reject`:: Inform the credential subsystem that the provided credentials have been rejected. This will cause the credenti