git-credential(1)

NAMN

git-credential - Hämta och lagra användaruppgifter

SYNOPSIS

git credential (fill|approve|reject|capability)

BESKRIVNING

Git har ett internt gränssnitt för att lagra och hämta inloggningsuppgifter från systemspecifika hjälpare, samt för att fråga användaren efter användarnamn och lösenord. Kommandot `git-credential` exponerar detta gränssnitt för skript som kanske vill hämta, lagra eller fråga efter inloggningsuppgifter på samma sätt som Git. Utformningen av detta skriptbara gränssnitt modellerar det interna C-API:et; se `credential.h` för mer bakgrundsinformation om koncepten.

`git-credential` tar ett "action"-alternativ på kommandoraden (ett av fill, approve eller reject) och läser en beskrivning av inloggningsuppgifterna från stdin (se INPUT/OUTPUT FORMAT).

Om åtgärden är fill kommer `git-credential` att försöka lägga till attributen "username" och "password" till beskrivningen genom att läsa konfigurationsfiler, genom att kontakta eventuella konfigurerade inloggningsuppgiftshjälpare eller genom att fråga användaren. Attributen username och password i beskrivningen av inloggningsuppgifterna skrivs sedan till stdout tillsammans med de attribut som redan tillhandahållits.

Om åtgärden är approve kommer `git-credential` att skicka beskrivningen till eventuella konfigurerade inloggningsuppgiftshjälpare, som kan lagra inloggningsuppgifterna för senare användning.

Om åtgärden är reject kommer `git-credential` att skicka beskrivningen till eventuella konfigurerade inloggningsuppgiftshjälpare, som kan radera eventuella lagrade inloggningsuppgifter som matchar beskrivningen.

Om åtgärden är capability kommer `git-credential` att annonsera eventuella funktioner som det stöder till standardutgången.

Om åtgärden är approve eller reject ska ingen utmatning ske.

TYPISK ANVÄNDNING AV GIT CREDENTIAL

Ett program som använder `git-credential` kommer vanligtvis att använda `git credential` enligt följande steg:

1. Generera en beskrivning av inloggningsuppgifterna baserat på kontexten.
   Om vi till exempel vill ha ett lösenord för
   <https://example.com/foo.git>, kan vi generera följande beskrivning
   av inloggningsuppgifterna (glöm inte den tomma raden i slutet; den
   talar om för `git credential` att programmet har matat in all
   information det har):
       protocol=https
       host=example.com
       path=foo.git
2. Be `git-credential` att ge oss ett användarnamn och lösenord för denna
   beskrivning. Detta görs genom att köra `git credential fill` och mata
   in beskrivningen från steg (1) till dess standardinmatning. Den
   fullständiga beskrivningen av inloggningsuppgifterna (inklusive själva
   inloggningsuppgifterna, dvs. inloggning och lösenord) kommer att
   produceras på standardutgången, som:
       protocol=https
       host=example.com
       username=bob
       password=secr3t
   I de flesta fall innebär detta att de attribut som anges i inmatningen
   kommer att upprepas i utmatningen, men Git kan också ändra
   beskrivningen av inloggningsuppgifterna, till exempel genom att ta bort
   attributet `path` när protokollet är HTTP(s) och
   `credential.useHttpPath` är falskt.
   Om `git credential` kände till lösenordet, kan detta steg ha skett utan
   att användaren faktiskt behövde skriva in lösenordet (användaren kan ha
   skrivit in ett lösenord för att låsa upp nyckelringen istället, eller
   ingen användarinteraktion skedde om nyckelringen redan var upplåst)
   innan det returnerade `password=secr3t`.
3. Använd inloggningsuppgifterna (t.ex. anslut till URL:en med användarnamnet
   och lösenordet från steg (2)) och se om de accepteras.
4. Rapportera om lösenordet accepterades eller inte. Om inloggningsuppgifterna
   tillät att operationen slutfördes framgångsrikt, kan de markeras med
   åtgärden "approve" för att tala om för `git credential` att återanvända
   dem vid nästa anrop. Om inloggningsuppgifterna avvisades under
   operationen, använd åtgärden "reject" så att `git credential` kommer
   att fråga efter ett nytt lösenord vid nästa anrop. I båda fallen ska
   `git credential` matas med den beskrivning av inloggningsuppgifterna
   som erhölls från steg (2) (som också innehåller de fält som
   tillhandahölls i steg (1)).

INPUT/OUTPUT FORMAT

`git credential` läser och/eller skriver (beroende på vilken åtgärd som används) information om inloggningsuppgifter i sin standardinmatning/utmatning. Denna information kan antingen motsvara nycklar för vilka `git credential` kommer att hämta inloggningsinformationen (t.ex. host, protocol, path), eller själva inloggningsuppgifterna som ska hämtas (username/password).

Inloggningsuppgifterna delas upp i en uppsättning namngivna attribut, med ett attribut per rad. Varje attribut specificeras av ett nyckel-värde-par, separerat av ett `=` (likhetstecken), följt av en nyrad.

Nyckeln kan innehålla alla bytes utom `=`, nyrad eller NUL. Värdet kan innehålla alla bytes utom nyrad eller NUL. En rad, inklusive den avslutande nyraden, får inte överstiga 65535 bytes för att tillåta effektiva parsningar i implementeringarna.

Attribut vars nycklar slutar med C-liknande array-klammer `[]` kan ha flera värden. Varje instans av ett flervärdesattribut bildar en ordnad lista av värden - ordningen på de upprepade attributen definierar ordningen på värdena. Ett tomt flervärdesattribut (`key[]=\n`) rensar eventuella tidigare poster och återställer listan.

I alla fall behandlas alla bytes som de är (dvs. det finns ingen citering, och man kan inte överföra ett värde med nyrad eller NUL i det). Listan med attribut avslutas med en tom rad eller filslut.

Git förstår följande attribut:

protocol

Protokollet över vilket inloggningsuppgifterna kommer att användas (t.ex.

 `https`).

host

Värdnamnet för en nätverksinloggningsuppgift. Detta inkluderar portnumret

 om ett sådant angavs (t.ex. "example.com:8088").

path

Sökvägen med vilken inloggningsuppgifterna kommer att användas. T.ex. vid

 åtkomst till ett fjärranslutet https-arkiv, kommer detta att vara arkivets
 sökväg på servern.

username

Inloggningsuppgiftens användarnamn, om vi redan har ett (t.ex. från en URL,

 konfigurationen, användaren eller från en tidigare körd hjälpare).

password

Inloggningsuppgiftens lösenord, om vi ber att det ska lagras.

password_expiry_utc

Genererade lösenord som t.ex. en OAuth-åtkomsttoken kan ha ett

 utgångsdatum. Vid läsning av inloggningsuppgifter från hjälpare ignorerar
 `git credential fill` utgångna lösenord. Representeras som Unix-tid UTC,
 sekunder sedan 1970.

oauth_refresh_token

En OAuth-uppdateringstoken kan följa med ett lösenord som är en

 OAuth-åtkomsttoken. Hjälpare måste behandla detta attribut som konfidentiellt
 likt lösenordsattributet. Git självt har inget speciellt beteende för detta
 attribut.

url

När detta speciella attribut läses av `git credential` parsas värdet som

 en URL och behandlas som om dess beståndsdelar lästes in (t.ex.
 `url=https://example.com` skulle bete sig som om `protocol=https` och
 `host=example.com` hade angetts). Detta kan hjälpa anropare att undvika
 att själva behöva parsa URL:er.
 Observera att specificering av ett protokoll är obligatoriskt och om URL:en
 inte specificerar ett värdnamn (t.ex. "cert:///path/to/file") kommer
 inloggningsuppgifterna att innehålla ett värdnamnsattribut vars värde är
 en tom sträng.
 Komponenter som saknas i URL:en (t.ex. det finns inget användarnamn i
 exemplet ovan) kommer att lämnas odefinierade.

authtype

Detta indikerar att det aktuella autentiseringsschemat ska användas.

 Vanliga värden för HTTP och HTTPS inkluderar `basic`, `bearer` och
 `digest`, även om det senare är osäkert och inte bör användas. Om
 `credential` används kan detta sättas till en godtycklig sträng som är
 lämplig för det aktuella protokollet (vanligtvis HTTP).
 Detta värde ska inte skickas om inte lämplig funktion (se nedan)
 tillhandahålls i inmatningen.

credential

Den förkodade inloggningsuppgiften, lämplig för det aktuella protokollet

 (vanligtvis HTTP). Om denna nyckel skickas är `authtype` obligatoriskt,
 och `username` och `password` används inte. För HTTP sammanfogar Git
 värdet för `authtype` och detta värde med ett enda mellanslag för att
 bestämma `Authorization`-huvudet.
 Detta värde ska inte skickas om inte lämplig funktion (se nedan)
 tillhandahålls i inmatningen.

ephemeral

Detta booleska värde indikerar, om sant, att värdet i fältet `credential`

 inte ska sparas av inloggningsuppgiftshjälparen eftersom dess användbarhet
 är tidsbegränsad. Till exempel beräknas ett HTTP Digest `credential`-värde
 med hjälp av en nonce och återanvändning av det kommer inte att leda till
 framgångsrik autentisering. Detta kan också användas i situationer med
 kortvariga (t.ex. 24-timmars) inloggningsuppgifter. Standardvärdet är falskt.
 Inloggningsuppgiftshjälparen kommer fortfarande att anropas med `store`
 eller `erase` så att den kan avgöra om operationen lyckades.
 Detta värde ska inte skickas om inte lämplig funktion (se nedan)
 tillhandahålls i inmatningen.

state[]

Detta värde tillhandahåller ett opakt tillstånd som kommer att skickas

 tillbaka till denna hjälpare om den anropas igen. Varje olika
 inloggningsuppgiftshjälpare kan specificera detta en gång. Värdet bör
 innehålla ett prefix som är unikt för inloggningsuppgiftshjälparen och
 bör ignorera värden som inte matchar dess prefix.
 Detta värde ska inte skickas om inte lämplig funktion (se nedan)
 tillhandahålls i inmatningen.

continue

Detta är ett booleskt värde som, om aktiverat, indikerar att denna

 autentisering är en icke-slutgiltig del av ett flerstegs
 autentiseringssteg. Detta är vanligt i protokoll som NTLM och Kerberos,
 där två omgångar av klientautentisering krävs, och att sätta denna flagga
 gör det möjligt för inloggningsuppgiftshjälparen att implementera
 flerstegsautentiseringssteget. Denna flagga ska endast skickas om ett
 ytterligare steg krävs; det vill säga om ytterligare en autentiseringsomgång
 förväntas.
 Detta värde ska inte skickas om inte lämplig funktion (se nedan)
 tillhandahålls i inmatningen. Detta attribut är *enkelriktat* från en
 inloggningsuppgiftshjälpare för att skicka information till Git (eller
 andra program som anropar `git credential`).

wwwauth[]

När ett HTTP-svar tas emot av Git som innehåller ett eller flera

 `WWW-Authenticate`-autentiseringshuvuden, kommer dessa att skickas av Git
 till inloggningsuppgiftshjälpare.
 Varje `WWW-Authenticate`-huvudvärde skickas som ett flervärdesattribut
 `wwwauth[]`, där ordningen på attributen är densamma som de visas i
 HTTP-svaret. Detta attribut är *enkelriktat* från Git för att skicka
 ytterligare information till inloggningsuppgiftshjälpare.

capability[]

Detta signalerar att Git, eller hjälparen, i förekommande fall, stöder den

 aktuella funktionen. Detta kan användas för att tillhandahålla bättre, mer
 specifik data som en del av protokollet. En `capability[]`-direktiv måste
 föregå alla värden som beror på den, och dessa direktiv *bör* vara det
 första som annonseras i protokollet.
 Det finns för närvarande två funktioner som stöds. Den första är `authtype`,
 vilket indikerar att värdena `authtype`, `credential` och `ephemeral`
 förstås. Den andra är `state`, vilket indikerar att värdena `state[]` och
 `continue` förstås.
 Det är inte obligatoriskt att använda de ytterligare funktionerna bara
 för att funktionen stöds, men de bör inte tillhandahållas utan funktionen.

Icke-igenkända attribut och funktioner ignoreras tyst.

CAPABILITY INPUT/OUTPUT FORMAT

För `git credential capability` är formatet något annorlunda. Först görs ett `version 0`-meddelande för att indikera den aktuella versionen av protokollet, och sedan annonseras varje funktion med en rad som `capability authtype`. Inloggningsuppgiftshjälpare kan också implementera detta format, återigen med argumentet `capability`. Ytterligare rader kan läggas till i framtiden; anropare bör ignorera rader som de inte förstår.

Eftersom detta är en ny del av protokollet för inloggningsuppgiftshjälpare kan äldre versioner av Git, samt vissa inloggningsuppgiftshjälpare, inte stödja det. Om en avslutningsstatus som inte är noll tas emot, eller om den första raden inte börjar med ordet `version` och ett mellanslag, bör anropare anta att inga funktioner stöds.

Avsikten med detta format är att på ett entydigt sätt skilja det från utmatningen av inloggningsuppgifter. Det är möjligt att använda mycket enkla inloggningsuppgiftshjälpare (t.ex. inline-skalskript) som alltid producerar identisk utmatning. Att använda ett distinkt format gör det möjligt för användare att fortsätta använda denna syntax utan att behöva oroa sig för att korrekt implementera funktionsannonseringar eller oavsiktligt förvirra anropare som frågar efter funktioner.

GIT

Del av git(1)-sviten

KOLOFON

Den här sidan är en del av projektet *git* (Git distribuerat versionshanteringssystem). Information om projektet hittar du på ⟨http://git-scm.com/⟩. Om du har en felrapport för den här manualsidan, se ⟨http://git-scm.com/community⟩. Den här sidan hämtades från projektets uppströms Git-arkiv ⟨https://github.com/git/git.git⟩ den 2025-02-02. (Vid det tillfället var datumet för den senaste commit som hittades i arkivet 2025-01-31.) Om du upptäcker några renderingsproblem i den här HTML-versionen av sidan, eller om du tror att det finns en bättre eller mer aktuell källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i denna KOLOFON (som *inte* är en del av den ursprungliga manualsidan), skicka ett e-postmeddelande till man-pages@man7.org

Sidslut

Orginalhemsidan på Engelska :https://man7.org/linux/man-pages/man1/git-credential.1.html

---

Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till PC-Service som har sponsrat Linux.se med webbhotell.