网络模型

优质

小牛编辑

130浏览

2023-12-01

网络模型

在某些情况下，你需要理解Subversion客户端如何与服务器通讯。Subversion网络层是抽象的，意味着Subversion客户端不管其操作的对象都会使用相同的行为方式，不管是使用HTTP协议（http://）与Apache HTTP服务器通讯或是使用自定义Subversion协议（svn://）与svnserve通讯，基本的网络模型是相同的。在本小节，我们要解释网络模型基础，包括Subversion如何管理认证和授权信息。

请求和响应

Subversion客户端花费大量的时间来管理工作拷贝，当它需要远程版本库的信息，它会做一个网络请求，然后服务器给一个恰当的回答，具体的网络协议细节对用户不可见，客户端尝试去访问一个URL，根据URL模式的不同，会使用特定的协议与服务器联系（见版本库的URL）。

提示

用户可以运行svn --version来查看客户端可以使用的URL模式和协议。

当服务器处理一个客户端请求，它通常会要求客户端确定它自己的身份，它会发出一个认证请求给客户端，而客户端通过提供凭证给服务器作为响应，一旦认证结束，服务器会响应客户端最初请求的信息。注意这个系统与CVS之类的系统不一样，它们会在请求之前，预先提供凭证（“logs in”）给服务器，在Subversion里，服务器通过请求客户端适时地“拖入”凭证，而不是客户端“推”出，这使得这种操作更加的优雅。例如，如果一个服务器配置为世界上的任何人都可以读取版本库，在客户使用svn checkout时，服务器永远不会发起一个认证请求。

如果客户端的请求会在版本库创建新的修订版本（例如svn commit），Subversion就会使用认证过的用户名作为此次提交的作者。也就是说经过认证的用户名作为svn:author属性的值保存到新的修订本里（见“Subversion属性”一节）。如果客户端没有经过认证（换句话说，服务器没有发起过认证请求），这时修订本的svn:author的值是空的。

客户端凭证缓存

许多服务器配置为每次请求要求认证，对被强制每次输入用户名密码，许多用户会感到很讨厌。幸运的是，Subversion客户端对此有一个修补—存在一个在磁盘上保存认证凭证缓存的系统，缺省情况下，当一个命令行客户端成功的响应了服务器的认证请求，它会保存一个认证文件到用户的私有运行配置区（类Unix系统下会在~/.subversion/auth/，Windows下在%APPDATA%/Subversion/auth/，运行配置系统在“运行配置区”一节会有更多细节描述）。成功的凭证会缓存在磁盘，以主机名、端口和认证域的组合作为唯一性区别。

当客户端接收到一个认证请求，它会首先查找用户磁盘中的认证凭证缓存，如果没有发现，或者是缓存的凭证认证失败，客户端会提示用户提供需要的信息。

十分关心安全的人们一定会想“把密码缓存在磁盘？太可怕了，永远不要这样做！”

Subversion开发者认识到这种关注的正确性，所以Subversion使用操作系统和环境提供的机制来减少泄露这些信息的风险，下面是在大多数平台上这种含义的列表：

在Windows 2000或更新的系统上，Subversion客户端使用标准Windows加密服务来加密磁盘上的密码。因为加密密钥是Windows管理的，与用户的登陆凭证相关，只有用户可以解密密码。（注意：如果用户的Windows账户密码被管理员重置，所有的缓存密码就不可以解密了，此时Subversion客户端就会当它们根本不存在，在需要时继续询问密码。）
类似的，在Mac OS X，Subversion客户端在登陆keyring（使用Keychain管理）保存了所有的版本库密码，使用户用帐号密码保护。用户选择的设置可以强加额外的政策，例如在需要用户密码时要求输入用户帐号密码。
对于其他类Unix系统，没有标准的加密服务。然而auth/缓存区只有用户（拥有者）可以访问，而不是全世界都可以，操作系统的访问许可可以保护密码文件。

当然，对于真正的妄想狂，没有任何机制是完美的。这类人希望用无限的安全来牺牲便利性，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文件，只需要把store-auth-creds设置为no，这样在影响的主机上的Subversion操作就不会有凭证缓存在磁盘。通过修改系统级的运行配置区，这个功能也会影响到本机的所有用户（详细内容见“配置区布局”一节）。

[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

一旦你定位了正确的缓存文件，只需要删除它。

svn--username--password--username--passwordsvn

这里是Subversion客户端在收到认证请求的时候的行为方式最终总结：

首先，检查用户是否通过命令选项（--username和/或--password）指定了任何凭证信息，如果没有，或者这些选项没有认证成功，然后
查找运行中的auth/区域保存的服务器名，端口和认证域信息，来确定用户是否已经有了恰当的认证缓存，如果没有，或者缓存凭证认证失败，然后
最终，客户端返回要求用户（除非使用--non-interactive选项或客户端对等的方式）。

如果客户端通过以上的任何一种方式成功认证，它会尝试在磁盘缓存凭证（除非用户已经关闭了这种行为方式，在前面提到过。）