This section is a general discussion of how a Subversion client and server interact with one another, regardless of the network implementation you're using. After reading, you'll have a good understanding of how a server can behave and the different ways in which a client can be configured to respond.
The Subversion client spends most of its time managing working copies. When it needs information from a repository, however, it makes a network request, and the server responds with an appropriate answer. The details of the network protocol are hidden from the user; the client attempts to access a URL, and depending on the URL schema, a particular protocol is used to contact the server (see Repository URLs). Users can run svn --version to see which URL schemas and protocols the client knows how to use.
When the server process receives a client request, it typically demands that the client identify itself. It issues an authentication challenge to the client, and the client responds by providing credentials back to the server. Once authentication is complete, the server responds with the original information the client asked for. Notice that this system is different from systems like CVS, where the client pre-emptively offers credentials (“logs in”) to the server before ever making a request. In Subversion, the server “pulls” credentials by challenging the client at the appropriate moment, rather than the client “pushing” them. This makes certain operations more elegant. For example, if a server is configured to allow anyone in the world to read a repository, then the server will never issue an authentication challenge when a client attempts to svn checkout.
If the client's network request writes new data to the
repository (e.g. svn commit), then a new
revision tree is created. If the client's request was
authenticated, then the authenticated user's name is stored as
the value of the svn:author property on the
new revision (see the section called “Unversioned Properties”). If
the client was not authenticated (in other words, the server
never issued an authentication challenge), then the revision's
svn:author property is empty.
[22]
Many servers are configured to require authentication on every request. This can become a big annoyance to users, who are forced to type their passwords over and over again.
Happily, the Subversion client has a remedy for this: a
built-in system for caching authentication credentials on
disk. By default, whenever the command-line client
successfully responds to a server's authentication challenge,
it saves the credentials in the user's private runtime
configuration
area—in ~/.subversion/auth/ on
Unix-like systems or
%APPDATA%/Subversion/auth/ on Windows.
(The runtime area is covered in more detail in the section called “Runtime Configuration Area”.) Successful credentials are
cached on disk, keyed on a combination of hostname, port, and
authentication realm.
When the client receives an authentication challenge, it first looks for the appropriate credentials in the user's disk cache; if not present, or if the cached credentials fail to authenticate, then the client simply prompts the user for the information.
Security-conscious people may be thinking to themselves, “Caching passwords on disk? That's terrible! You should never do that!” Please remain calm, it's not as dangerous as it sounds.
The auth/ caching area is
permission-protected so that only the user (owner) can
read data from it, not the world at large. The operating
system's own file permissions are protecting the
password.
On Windows 2000 and later, the Subversion client uses standard Windows cryptography services to encrypt the password on disk. Because the encryption key is managed by Windows and is tied to the user's own login credentials, only the user can decrypt the cached password. (Note: if the user's Windows account password is reset by an administrator, all of the cached passwords become undecipherable. The Subversion client will behave as if they don't exist, prompting for passwords when required.)
For the truly paranoid willing to sacrifice all convenience, it's possible to disable credential caching altogether.
To disable caching for a single command, pass the
--no-auth-cache option:
$ 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. # password was not cached, so a second commit still prompts us $ svn delete newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe …
Or, if you want to disable credential caching permanently,
you can edit your runtime config file
(located next to the auth/ directory).
Simply set store-auth-creds to
no, and no credentials will be cached on
disk, ever.
[auth] store-auth-creds = no
Sometimes users will want to remove specific credentials
from the disk cache. To do this, you need to navigate into
the auth/ area and manually delete the
appropriate cache file. Credentials are cached in individual
files; if you look inside each file, you will see keys and
values. The svn:realmstring key describes
the particular server realm that the file is associated
with:
$ 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
Once you have located the proper cache file, just delete it.
One last word about client authentication behavior: a bit
of explanation about the --username and
--password options is needed. Many client
subcommands accept these options; however it is important to
understand using these options does not
automatically send credentials to the server. As discussed
earlier, the server “pulls” credentials from the
client when it deems necessary; the client cannot
“push” them at will. If a username and/or
password are passed as options, they will
only be presented to the server if the
server requests them.
[23]
Typically, these options are used when:
the user wants to authenticate as a different user than her system login name, or
a script wants to authenticate without using cached credentials.
Here is a final summary that describes how a Subversion client behaves when it receives an authentication challenge:
Check whether the user specified any credentials as
command-line options, via --username
and/or --password. If not, or if these
options fail to authenticate successfully, then
Look up the server's realm in the runtime
auth/ area, to see if the user already
has the appropriate credentials cached. If not, or if the
cached credentials fail to authenticate, then
Resort to prompting the user.
If the client successfully authenticates by any of the methods listed above, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier).
[22] This problem is actually a FAQ, resulting from a misconfigured server setup.
[23] Again, a common mistake is to misconfigure a
server so that it never issues an authentication challenge.
When users pass --username and
--password options to the client,
they're surprised to see that they're never used, i.e. new
revisions still appear to have been committed
anonymously!