この節は実際に利用する具体的なネットワーク実装にかかわらず、 Subversion クライアントがどのようにしてサーバと通信するかの一般的な議論です。 この節を読み終えた後では、クライアントの応答についての設定によって サーバがどんな風に違った形で振る舞うかについて詳しく理解していることでしょう。
Subversion クライアントはほとんどの時間を作業コピーの管理に費やします。 しかしリポジトリからの情報が必要な場合にはネットワーク要求を発行し、 これに対してサーバが適切に応答します。ネットワークプロトコルの詳細は ユーザからは隠されています; クライアントは URL にアクセスしようとし、 URL スキーマの種類によって特定のプロトコルがサーバとの通信に利用され ます(リポジトリのURL)。ユーザはsvn --version を実行してSubversion クライアントがどの URL スキーマとプロトコル を利用できるかを知ることができます。
サーバプロセスがクライアント要求を受け取ると、普通はクライアントの認証を 要求します。クライアントに対して認証確認を実行し、クライアントは 認証証明を提示することでこれに答えます。いったん 認証が成功すればサーバはクライアントがそもそも要求していた情報を返します。 このシステムは CVS のようなシステムとは異なっていることに注意してください。 CVS などではクライアントは要求を出す前に、あらかじめ認証証明を (「ログインによって」)サーバに送ります。Subversion ではサーバは適当な時点 でクライアントにチャレンジの仕組みによって認証証明を 「要求」 します。 クライアントが自発的にサーバに 「送りつける」 わけではありません。 これはある種の操作をより洗練されたものにします。たとえばもしサーバが 世界中の誰でもそのリポジトリを読めるように設定すれば、クライアントが svn checkoutを実行するときに認証確認を実行せずに 済みます。
クライアントネットワーク要求が新しいデータをリポジトリに書き込む場合
(たとえば svn commit) 、新しいリビジョンツリーが
作成されます。もしクライアント要求が認証されれば認証されたユーザ名は
新しいリビジョンのsvn:author属性の値として
格納されます(「バージョン化されない属性」参照)。もしクライアント
が認証されなければ(言い換えるとサーバが認証確認に失敗すれば)、その
リビジョンのsvn:author属性は空となります。
[22]
多くのサーバは要求ごとに認証を要求するように設定されます。 これはユーザにとっては大きな苦痛となることがあります。常にパスワード を入力しなくてはならないからです。
ありがたいことに、Subversion クライアントはこれに対する処方箋が
あります: ディスク上での認証証明をキャッシュするための組み込みシステム
があります。デフォルトではコマンドラインクライアントがサーバに対する
認証に成功したときは常にユーザの実行時環境領域にその証明を保存します
— この場所はUnix 系システムでは~/.subversion/auth/、
Windows であれば %APPDATA%/Subversion/auth/に
なります。(実行時領域については、「実行時設定領域」
により詳しい説明があります)。成功した証明はディスクにキャッシュされ
ホスト名、ポート、認証方式の組み合わせをキーとして保存されます。
クライアントが認証確認を受けたとき、まずディスクキャッシュにある証明を探し ます; 存在しないかキャッシュされた証明が認証に失敗した場合はクライアントは ユーザに入力を求めるプロンプトを出します。
セキュリティー狂なら思うかも知れません、「パスワードをディスクにキャッシュ するだと? ひどすぎる。絶対やめろ!」 と。まあ落ち着いて。それは見かけほど 危険な状態ではありません。
auth/ のキャッシュ領域はパーミッションで保護されている
ので(所有者である)ユーザだけがそのデータを読むことができ、誰でもというわけでは
ありません。オペレーティングシステムのファイル所有権限はパスワードによって保護
されています。
Windows 2000 とそれ以降の場合、Subversion クライアントは標準的な Windows の 暗号サービスを利用してディスク上のパスワードを暗号化します。暗号キーはWindows によって管理されユーザ固有のログイン認証に結びついているのでそのユーザだけが キャッシュされたパスワードを復号化できます。(注意: ユーザの Windows アカウント パスワードが変更された場合、キャッシュされているすべてのパスワードは復号化不能 になります。Subversion クライアントはそれが存在していないかのような動作をし、 必要に応じてパスワードの入力をうながします。)
すべての利便性を犠牲にしてまでセキュリティーを確保したいという、本当にスジガネ入り のセキュリティー狂には、すべての認証キャッシュを完全に無効にすることも可能です。
単一のコマンド中でキャッシュ
を無効にする場合は --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 …
あるいは、証明のキャッシュをずっと無効にし続けたい場合は実行時
configファイルを編集してください(
auth/ディレクトリの隣にあります)。
単にstore-auth-credsをnoに
設定すればディスク上に証明書をキャッシュしなくなります。
[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
適切なキャッシュファイルを特定し、それを削除してください。
クライアント認証について最後に一つ: --username
と --passwordオプションについての説明が少し
必要です。たくさんのクライアントサブコマンドはこれらのオプションを
受け付けます; しかしこのようなオプションはサーバに自動的に証明を
送るのではないことに注意してください。既に
説明したようにサーバは必要に応じてクライアントに証明の提示を「要求」
します; クライアントから「自発的に提示する」ことはできないのです。
もしユーザ名とパスワードがオプションとして渡された場合でも、それは
サーバが要求したときにのみ提示されるのです。
[23]
典型的にはこれのようなオプションは以下のような場合に利用されます:
ユーザは自分のログイン名称とは違うユーザで認証を 受けたいか、
あるスクリプトがキャッシュされている証明なしに 認証を受けたい。
最後にどのようにしてSubversion クライアントが認証確認を受けたときに 振る舞うかをまとめておきます:
ユーザがコマンドラインオプション中で--username
または--passwordを通じて何らかの証明を指定しているか
どうかを確認します。指定していないか、オプションによる認証が失敗した
場合には、
実行時 auth/領域中でサーバの認証範囲を探して
ユーザが既に適切な証明をキャッシュしているかどうかを調べます。
もしそうでないかキャッシュされた証明が認証に失敗した場合はさらに、
ユーザに対して証明の入力をうながします。
クライアントが上記のどれかの方法で認証に成功した場合はディスク上にその 証明をキャッシュしようとします (既に述べたように、ユーザがこの動作 を無効にしない限り、そうします)。