Version Control with Subversion - Login

Advanced TopicsRun svn --version to see which URL schemes and protocols the clientknows how to use.When the server process receives a client request, it often demands that the client identifyitself. It issues an authentication challenge to the client, and the client responds by providingcredentials back to the server. Once authentication is complete, the server respondswith the original information that the client asked for. Notice that this system is differentfrom systems such as CVS, where the client preemptively offers credentials (“logs in”) tothe server before ever making a request. In Subversion, the server “pulls” credentials bychallenging 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 allowanyone in the world to read a repository, the server will never issue an authentication challengewhen a client attempts to svn checkout.If the particular network requests issued by the client result in a new revision being createdin the repository (e.g., svn commit), Subversion uses the authenticated username associatedwith those requests as the author of the revision. That is, the authenticated user'sname is stored as the value of the svn:author property on the new revision (see the sectioncalled “Subversion Properties”). If the client was not authenticated (i.e., if the servernever issued an authentication challenge), the revision's svn:author property is empty.Client Credentials CachingMany servers are configured to require authentication on every request. This would be abig annoyance to users if they were forced to type their passwords over and over again.Fortunately, the Subversion client has a remedy for this—a built-in system for caching authenticationcredentials on disk. By default, whenever the command-line client successfullyresponds to a server's authentication challenge, credentials are cached on disk and keyedon a combination of the server's hostname, port, and authentication realm.When the client receives an authentication challenge, it first looks for the appropriate credentialsin the user's disk cache. If seemingly suitable credentials are not present, or if thecached credentials ultimately fail to authenticate, the client will, by default, fall back toprompting the user for the necessary information.The security-conscious reader will suspect immediately that there is reason for concernhere. “Caching passwords on disk? That's terrible! You should never do that!”The Subversion developers recognize the legitimacy of such concerns, and so Subversionworks with available mechanisms provided by the operating system and environment to tryto minimize the risk of leaking this information. Here's a breakdown of what this means forusers on the most common platforms:• On Windows, the Subversion client stores passwords in the%APPDATA%/Subversion/auth/ directory. On Windows 2000 and later, the standardWindows cryptography services are used to encrypt the password on disk. Because theencryption 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 accountpassword 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 passwordswhen required.)• Similarly, on Mac OS X, the Subversion client stores all repository passwords in the loginkeyring (managed by the Keychain service), which is protected by the user's accountpassword. User preference settings can impose additional policies, such as requiringthat the user's account password be entered each time the Subversion password isused.82