客户端凭证缓存

 

客户端凭证缓存

许多服务器配置为在每次请求时要求认证，这对一次次输入用户名和密码的用户来说是非常恼人的事情。

令人高兴的是，Subversion客户端对此有一个修补：存在一个在磁盘上保存认证凭证缓存的系统，缺省情况下，当一个命令行客户端成功的在服务器上得到认证，它会保存一个认证文件到用户的私有运行配置区—类Unix系统下会在~/.subversion/auth/，Windows下在%APPDATA%/Subversion/auth/（运行区在“运行配置区”一节会有更多细节描述）。成功的凭证会缓存在磁盘，以主机名、端口和认证域的组合作为唯一性区别。

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

十分关心安全的人们一定会想“把密码缓存在磁盘？太可怕了，永远不要这样做！”但是请保持冷静，首先，auth/是访问保护的，只有用户（拥有者）可以读取这些数据，不是整个世界，如果这对你还不够安全，你可以关闭凭证缓存，只需要一个简单的命令，使用参数--no-auth-cache：

$ svn commit -F log_msg.txt --no-auth-cacheAuthentication realm: <svn://host.example.com:3690> example realmUsername:  joePassword for 'joe':Adding         newfileTransmitting file data .Committed revision 2324.# password was not cached, so a second commit still prompts us$ svn delete newfile$ svn commit -F new_msg.txtAuthentication realm: <svn://host.example.com:3690> example realmUsername:  joe[...]

或许，你希望永远关闭凭证缓存，你可以编辑你的运行配置文件（坐落在auth/目录），只需要把store-auth-creds设置为no，这样就不会有凭证缓存在磁盘。

[auth]store-auth-creds = no

有时候，用户希望从磁盘缓存删除特定的凭证，为此你可以浏览到auth/区域，删除特定的缓存文件，凭证都是作为一个单独的文件缓存，如果你打开每一个文件，你会看到键和值，svn:realmstring描述了这个文件关联的特定服务器的域：

$ ls ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28        3893ed123b39500bca8a0b382839198e5c3c22968347b390f349ff340196ed39$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28K 8usernameV 3joeK 8passwordV 4blahK 15svn:realmstringV 45<https://svn.domain.com:443> Joe's repositoryEND

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

客户端认证的行为的最后一点：对使用--username和--password选项的一点说明，许多客户端和子命令接受这个选项，但是要明白使用这个选项不会主动地发送凭证信息到服务器，就像前面讨论过的，服务器会在需要的时候才会从客户端“拖”入凭证，客户端不会随意“推”出。如果一个用户名和/或者密码作为选项传入，它们只会在服务器需要时展现给服务器。^[20]通常，只有在如下情况下才会使用这些选项：

• 用户希望使用与登陆系统不同的名字认证，或者

• 一段不希望使用缓存凭证但需要认证的脚本

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

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

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

3. 提示用户输入。

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

---

^[19] 这个问题实际上是一个FAQ，源自错误的服务器配置。

^[20] 再次重申，一个常见的错误是把服务器配置为从不会请求认证，当用户传递--username和--password给客户端时，他们惊奇的发现它们没有被使用，如新的修订版本看起来始终是由匿名用户提交的！