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 リポジトリのURL).
Run svn --version to see which URL schemes and protocols the client knows how to use.
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 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 particular network requests issued by the client result in a new revision being created in the repository, (e.g. svn commit), then 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 Subversion の属性項). 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.
Many servers are configured to require authentication on every request. This would be a big 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 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 (~/.subversion/auth/ on Unix-like systems or %APPDATA%/Subversion/auth/ on Windows; see 実行時設定領域項 for more details about the runtime configuration system). Successful credentials are cached on disk, keyed on a combination of the server's 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 seemingly suitable credentials are not present, or if the cached credentials ultimately fail to authenticate, then the client will, by default, fall back to prompting the user for the necessary information.
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!」
The Subversion developers recognize the legitimacy of such concerns, and so Subversion works with available mechanisms provided by the operating system and environment to try to minimize the risk of leaking this information. Here's a breakdown of what this means for users on the most common platforms:
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 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 if 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 the user's account password be entered each time the Subversion password is used.
For other Unix-like operating systems, no standard 「keychain」 services exist. However, 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.
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 security, Subversion provides various ways of disabling its credentials caching system altogether.
単一のコマンド中でキャッシュ を無効にする場合は --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. # 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 the config file in your runtime configuration area, and set the store-auth-creds option to no. This will prevent the storing of credentials used in any Subversion interactions you perform on the affected computer. This can be extended to cover all users on the computer, too, by modifying the system-wide runtime configuration area (described in 設定領域のレイアウト項).
[auth] store-auth-creds = no
ときどき特定の証明をディスクキャッシュから削除したくなることがあります。 これにはauth/領域を調べて適当なキャッシュファイルを 手で削除してください。証明は個別のファイルにキャッシュされています; それぞれ のファイルの中にはキーとその値があります。 svn:realmstring キーはファイルが関係している特定のサーバの認証範囲を記録しています:
$ 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
適切なキャッシュファイルを特定し、それを削除してください。
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 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. [20] 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).
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 not, or if these options fail to authenticate successfully, then
the client looks up the server's hostname, port, and 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
finally, the client resorts to prompting the user (unless instructed not to do so via the --non-interactive option or its client-specific equivalents).
クライアントが上記のどれかの方法で認証に成醐ｻ駈ｵた場合はディスク上にその 証明をキャッシュしようとします (既に述べたように、ユーザがこの動作 を無効にしない限り、そうします)。
[20] 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!