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 Subversion clients
      exhibit the same general behaviors no matter what sort of server
      they are operating against.  Whether speaking the HTTP protocol
      (http://) with the Apache HTTP Server or
      speaking the custom Subversion protocol
      (svn://) with svnserve,
      the basic network model is the same.  In this section, we'll
      explain the basics of that network model, including how
      Subversion manages authentication and authorization
      matters.
The Subversion client spends most of its time managing working copies. When it needs information from a remote 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 scheme, a particular protocol is used to contact the server (see the section called “Addressing the Repository”).
| ![[Tip]](images/tip.png)  | Tip | 
|---|---|
| Run  | 
When the server process receives a client request, it often 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 that the client asked for. Notice that this system is different from systems such as CVS, where the client preemptively 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, the server will never issue an authentication challenge when a client attempts to svn checkout.
If the particular network requests issued by the client
        result in a new revision being created in the repository
        (e.g., svn commit), Subversion uses the
        authenticated username associated with those requests as the
        author of the revision.  That is, the authenticated user's
        name is stored as the value of the
        svn:author property on the new revision
        (see the section called “Subversion Properties” in
        Chapter 9, Subversion Complete Reference).  If the client was not
        authenticated (i.e., if the server never issued an
        authentication challenge), the revision's
        svn:author property is empty.
Many Subversion servers are configured to require authentication. Sometimes anonymous read operations are allowed, while write operations must be authenticated. In other cases, reads and writes alike require authentication. Subversion's different server options understand different authentication protocols, but from the user's point of view, authentication typically boils down to usernames and passwords. Subversion clients offer several different ways to retrieve and store a user's authentication credentials, from interactive prompting for usernames and passwords to encrypted and non-encrypted on-disk data caches.
The security-conscious reader will suspect immediately that there is reason for concern here. “Caching passwords on disk? That's terrible! You should never do that!” Don't worry—it's not as bad as it sounds. The following sections discuss the various types of credential caches that Subversion uses, when it uses them, and how to disable that functionality in whole or in part.
Subversion offers a remedy for the annoyance caused when users are forced to type their usernames and passwords over and over again. By default, whenever the command-line client successfully responds to a server's authentication challenge, credentials are cached on disk and keyed on a combination of the server's hostname, port, and authentication realm. This cache will then be automatically consulted in the future, avoiding the need for the user to re-type his or her authentication credentials. If seemingly suitable credentials are not present in the cache, or if the cached credentials ultimately fail to authenticate, the client will, by default, fall back to prompting the user for the necessary information.
The Subversion developers recognize that on-disk caches of authentication credentials can be a security risk. To offset this, Subversion works with available mechanisms provided by the operating system and environment to try to minimize the risk of leaking this information.
On Windows, the Subversion client stores passwords
              in the %APPDATA%/Subversion/auth/
              directory.  On Windows 2000 and later, the standard
              Windows cryptography services are used 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 that 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 though they don't exist, prompting for
              passwords when required.)
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 that the user's account password be entered each time the Subversion password is used.
For other Unix-like operating systems, no single
              standard “keychain” service exists.
              However, the Subversion client knows how to store
              passwords securely using the “GNOME Keyring”
              and “KDE Wallet” services.  Also, before
              storing unencrypted passwords in the
              ~/.subversion/auth/ caching area,
              the Subversion client will ask the user for permission
              to do so.  Note that the auth/
              caching area is still 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 protect
              the passwords from other non-administrative users on the
              same system, provided they have no direct physical access
              to the storage media of the home directory, or backups
              thereof.
Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials caching system altogether.
When you perform a Subversion operation that requires you to authenticate, by default Subversion tries to cache your authentication credentials on disk in encrypted form. On some systems, Subversion may be unable to encrypt your authentication data. In those situations, Subversion will ask whether you want to cache your credentials to disk in plaintext:
$ svn checkout https://host.example.com:443/svn/private-repo ----------------------------------------------------------------------- ATTENTION! Your password for authentication realm: <https://host.example.com:443> Subversion Repository can only be stored to disk unencrypted! You are advised to configure your system so that Subversion can store passwords encrypted, if possible. See the documentation for details. You can avoid future appearances of this warning by setting the value of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/tmp/servers'. ----------------------------------------------------------------------- Store password unencrypted (yes/no)?
If you want the convenience of not having to continually
          reenter your password for future operations, you can
          answer yes to this prompt.  If you're
          concerned about caching your Subversion passwords in
          plaintext and do not want to be asked about it again and
          again, you can disable caching of plaintext passwords either
          permanently, or on a server-per-server basis.
| ![[Warning]](images/warning.png)  | Warning | 
|---|---|
| When considering how to use Subversion's password caching system, you'll want to consult any governing policies that are in place for your client computer—many companies have strict rules about the ways that their employees' authentication credentials should be stored. | 
To permanently disable caching of passwords in
          plaintext, add the line store-plaintext-passwords =
          no to the [global] section in
          the servers configuration file on the
          local machine.  To disable plaintext password caching for a
          particular server, use the same setting in the appropriate
          group section in the servers
          configuration file.  (See
          the section called “Configuration Options” in
          Chapter 7, Customizing Your Subversion Experience for details.)
To disable password caching entirely for any single
          Subversion command-line operation, pass
          the --no-auth-cache option to that command
          line.  To permanently disable caching entirely, add the
          line store-passwords = no to your local
          machine's Subversion configuration file.
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.
All Subversion command-line operations accept
          the --username
          and --password options, which allow you to
          specify your username and password, respectively, so that
          Subversion isn't forced to prompt you for that information.
          This is especially handy if you need to invoke Subversion
          from a script and cannot rely on Subversion being able to
          locate valid cached credentials for you.  These options are
          also helpful when Subversion has already cached
          authentication credentials for you, but you know they aren't
          the ones you want it to use.  Perhaps several system users
          share a login to the system, but each have distinct
          Subversion identities.  You can omit
          the --password option from this pair if
          you wish Subversion to use only the provided username, but
          still prompt you for that username's password.
One last word about svn's
          authentication behavior, specifically regarding the
          --username and --password
          options.  Many client subcommands accept these options, but it
          is important to understand that 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 be
          presented to the server only if the server requests them.  These
          options are typically used to authenticate as a different user
          than Subversion would have chosen by default (such as your
          system login name) or when trying to avoid interactive
          prompting (such as when calling svn from a
          script).
| ![[Note]](images/note.png)  | Note | 
|---|---|
| A common mistake is to misconfigure a server so
            that it never issues an authentication challenge.  When
            users pass  | 
Here is a final summary that describes how a Subversion client behaves when it receives an authentication challenge.
First, the client checks whether the user specified
              any credentials as command-line options
              (--username and/or
              --password).  If so, the client will try
              to use those credentials to authenticate against the
              server.
If no command-line credentials were provided, or the
              provided ones were invalid, the client looks up the server's
              hostname, port, and realm in the runtime configuration's
              auth/ area, to see whether appropriate 
              credentials are cached there.  If so, it attempts to use
              those credentials to authenticate.
Finally, if the previous mechanisms failed to
              successfully authenticate the user against the server, the
              client resorts to interactively prompting the user for
              valid credentials (unless instructed not to do so via the
              --non-interactive option or its
              client-specific equivalents).
If the client successfully authenticates by any of these methods, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier).