At some point, you're going to need to understand how your
Subversion client communicates with its server. Subversion's
networking layer is abstracted, meaning that the Subversion
client exhibits the same general behaviors no matter what sort
of server it speaks with. Whether it's talking to Apache
via http:// or
with svnserve via svn://,
it responds to authentication challenges in the same ways, and
even caches your login name and password for you. This section
discusses these behaviors and shows you how to manage them to
your liking.
Subversionklienten bruker mesteparten av tida til å behandle arbeidskopier. Men når den trenger informasjon fra et depot foretar den en nettverksforespørsel og serveren kommer med et passende svar. Detaljene i nettverksprotokollen er skjult for brukeren; klienten prøver å aksessere en URL, og alt etter hvilket URL-skjema som brukes blir en passende protokoll brukt for å aksessere serveren (se Depot-URLer). Brukere kan kjøre svn --version for å se hvilke URL-skjema og protokoller klienten kan bruke.
Når serveren mottar en klientforespørsel, forlanger den vanligvis at klienten identifiserer seg. Den utsteder en autentiseringsforespørsel til klienten, og klienten svarer ved å legitimere seg ovenfor serveren. Når autentiseringen er komplett, svarer serveren med den originale informasjonen klienten spurte etter. Legg merke til at dette systemet er forskjellig fra systemer som CVS, hvor klienten på forhånd oppgir legitimasjon (“logger inn”) til serveren før noen forespørsel etter informasjon blir gjort. I Subversion “henter” serveren legitimasjonen ved å kontrollere klienten på det nødvendige tidspunktet i stedet for at klienten uoppfordret “leverer” den. Dette gjør visse operasjoner mer elegant. For eksempel, hvis en server er konfigurert til å la alle i hele verden få lese depotet, vil serveren aldri be om autentisering når klienten prøver en svn checkout.
Hvis klientens nettverksforespørsel skriver nye data til
depotet (for eksempel svn commit), vil et
nytt revisjonstre bli opprettet.
Hvis klientens forespøsel ble autentisert, blir brukernavnet til
den autentiserte brukeren lagret i
svn:author-egenskapen i den nye revisjonen
(se “Uversjonerte egenskaper”).
Hvis klienten ikke ble autentisert (med andre ord, serveren
spurte ikke etter legitimasjon), er revisjonens
svn:author-egenskap tom.[19]
Mange servere er satt opp til å forlange autentisering for hver eneste forespørsel. Dette kan bli et stort irritasjonsmoment for brukerne, som blir tvunget til å skrive passordet om og om igjen.
Heldigvis har Subversion en løsning på dette:
Et innebygget system for å lagre legitimasjonen på disk.
Normalt sett, når kommandolinjeklienten klarer å svare riktig på
en autentiseringsforespørsel fra en server, lagres denne
legitimasjonsinformasjonen i brukerens private konfigurasjonsområde – i
~/.subversion/auth/ på Unix-lignende
systemer eller %APPDATA%/Subversion/auth/ i
Windows.
(Konfigurasjonsområdet er dekket
mer inngående i “Konfigurasjonsområdet for bruk under kjøring”.)
Data fra vellykkede autentiseringer lagres på disken, der
nøkkelen er en kombinasjon av servernavn, port og området der
autentiseringen gjelder.
Når klienten må gjennom en autentiseringsprosess, ser den først etter passende legitimasjonsdata i brukerens lager på disken. Hvis dette ikke finnes, eller de lagrede legitimasjonsdataene ikke er tilstrekkelig for å fullføre autentiseringen, spør klienten ganske enkelt brukeren etter informasjonen.
Sikkerhetsbevisste folk tenker nok med seg selv: “Lagre passord på disken? Det er forferdelig! Sånt skal aldri gjøres!” Men ta det med ro, det er ikke så farlig som det høres ut.
På Windows 2000 og senere bruker Subversionklienten standard kryptografitjenester i Windows for å kryptere passordet på disken. Fordi krypteringsnøkkelen blir vedlikeholdt av Windows og den er forbundet med brukerens egne innloggingsbrukerdata, kan bare brukeren dekryptere det lagrede passordet. (Merk: Hvis brukerens passord i Windows blir resatt av en administrator, kan ikke de lagrede passordene dekrypteres. Subversionklienten vil oppføre seg som om de ikke eksisterer og spørre etter passord når det er nødvendig.)
Similarly, on Mac OS X, the Subversion client stores all repository passwords in the login keyring (managed by the Keychain service), which is protected by the user's account password. User preference settings can impose additional policies, such as requiring the user's account password be entered each time the Subversion password is used.
For andre Unix-lignende operativsystemer eksisterer det
ingen standardiserte “nøkkelring”-tjenester.
Imidlertid er lagringsområdet i auth/
fortsatt beskyttet av rettigheter så bare brukeren (eieren)
kan lese dataene derfra, ikke resten av verden.
Operativsystemets egne filrettigheter beskytter
passordet.
For den sanne paranoide som er villig til å ofre behageligheter, er det alltids mulig å deaktivere all lagring av legitimasjonsdata.
For å forhindre lagring for en enkelt kommando, spesifiser
valget --no-auth-cache:
$ svn commit -F log_msg.txt --no-auth-cache Authentication realm: <svn://host.example.com:3690> example realm Username: joe Password for 'joe': Adding newfile Transmitting file data . Committed revision 2324. # Passordet ble ikke lagret, så ved neste innlegging blir vi spurt på # nytt. $ svn delete newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe …
Eller, hvis du vil slå av lagring av legitimasjonen
permanent, kan du redigere config-fila
(plassert ved siden av auth/-katalogen).
Ved å sette store-auth-creds til
no vil ingen legitimasjon bli lagret på
disken i det hele tatt.
[auth] store-auth-creds = no
Noen ganger vil brukere ønske å fjerne spesifikke
legitimasjonsdata fra disklageret.
For å gjøre dette, må du gå inn i
auth/-området og manuelt slette den
aktuelle fila.
Legitimasjonen er lagret i individuelle filer, og hvis du ser på
hver fil, vil du se nøkler og verdier.
svn:realmstring-nøkkelen viser hvilket
serverområde fila er assosiert med:
$ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END
Når du har funnet den riktige fila, er det bare å slette den.
Et siste ord om oppførselen under klientautentisering, en
liten forklaring angående --username og
--password er på sin plass.
Mange delkommandoer for klienten godtar disse valgene, men det
er viktig å forstå at bruken av disse valgene sender
ikke brukerdata til serveren.
Som tidligere nevnt, “henter” serveren
brukerdata fra klienten når det er nødvendig; klienten kan ikke
“levere” dataene når den vil.
Hvis et brukernavn og/eller passord blir spesifisert som valg,
vil de bare bli gitt til serveren hvis
serveren spør etter dem.[20]
Vanligvis blir disse valgene brukt når:
brukeren vil identifisere seg som en annen bruker enn brukernavnet på systemet, eller
et skript vil identifisere seg uten å bruke lagrede brukerdata.
Her er en avsluttende oversikt som beskriver hvordan en Subversionklient oppfører seg når den mottar en autentiseringsforespørsel:
Sjekk om brukeren spesifiserte noen brukerdata som
kommandolinjevalg med --username og/eller
--password.
Hvis ikke, eller hvis disse valgene ikke er i stand til å
fullføre autentiseringen,
Let opp serverens område i
auth/-området for å se om brukeren
allerede har lagret de nødvendige identifikasjonsdataene.
Hvis ikke, eller hvis de lagrede brukerdataene ikke er
tilstrekkelig for å autentisere,
Spør brukeren.
Hvis klienten klarer å legitimere seg ved hjelp av noen av metodene nevnt ovenfor, vil den prøve å lagre brukerdataene på disken (unntatt hvis brukeren har slått av denne oppførselen, som tidligere nevnt).
[19] Dette er egentlig et spørsmål som ofte dukker opp som et resultat av feil i konfigurasjonen på serveren.
[20] Som sagt, en vanlig feil er å feilkonfigurere
serveren så den aldri spør etter autentiseringsinfo.
Når brukere angir --username og
--password til klienten, blir de overrasket
over å se at dataene aldri blir brukt og at nye revisjoner
fortsatt ser ut til å ha blitt lagt inn anonymt!