3.网络模型

Posted on Posted in 4.高级主题

网络模型

在某些情况下,你需要理解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客户端在收到认证请求的时候的行为方式最终总结:

  1. 首先,检查用户是否通过命令选项(–username和/或–password)指定了任何凭证信息,如果没有,或者这些选项没有认证成功,然后

  2. 查找运行中的auth/区域保存的服务器名,端口和认证域信息,来确定用户是否已经有了恰当的认证缓存,如果没有,或者缓存凭证认证失败,然后

  3. 最终,客户端返回要求用户(除非使用–non-interactive选项或客户端对等的方式)。

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