安全复制的分步说明？

安全传输用户凭据是一个非常棘手的问题。

如果我们不想第三方，在大多数情况下，SSL是更好的开始方式，因为它可能会被您使用的每个工具广泛支持。 SSL证书，不仅提供加密（甚至是自签名的加密），还提供用户请求正确资源的保险。 如果您关心服务器安全性，最后一个选项也值得强调。 SSL使用的主要缺点是性能下降（因使用的算法而异），因为服务器必须解密数据，并且除了常见的通信例程之外，客户端还需要验证证书。 此外，你必须为可靠的证书支付一些钱（ 并非总是如此 ）。

使用OAuth可以不泄露真实的用户凭据，并且可以轻松地从服务器端维护其访问控制。 此外，您需要一些能够正确处理OAuth 1.0规范的库，如果您的平台错过了 - 您必须自己实现它。 另外OAuth提供传输数据签名，因此它旨在为MiTM案例提供安全保障。 这实际上就是他所做的一切。

如您所知，SSL和OAuth有两个不同的东西：SSL有助于在传输级别（TLS）上加密数据，而OAuth会在非安全环境中处理凭据泄露。 它们不是彼此的替代品，但是它们中的每一个都可以替代其他的。

要为CouchDB设置SSL支持，请按照文档指南进行操作 。 这很简单易行。 请注意，如果CouchDB前面有一些代理服务器，那么为他设置SSL并通过常规HTTP协议将代理数据代理到本地CouchDB实例可能是明智之举。

要设置OAuth，需要执行以下步骤：0。确保{couch_httpd_oauth, oauth_authentication_handler} [httpd]部分的authentication_handlers选项的{couch_httpd_oauth, oauth_authentication_handler}处理程序存在于default.ini配置文件中：

[httpd] authentication_handlers = {couch_httpd_oauth，oauth_authentication_handler}，{couch_httpd_auth，cookie_authentication_handler}，{couch_httpd_auth，default_authentication_handler}

之后，您需要以下一种方式编辑local.ini文件：

1. 设置消费者秘密：

[oauth_consumer_secrets] 
example.org = sekr1t

1. 设置令牌机密：

[oauth_token_secrets] 
token1 = tokensekr1t

1. 将令牌映射到已存在的CouchDB用户：

[oauth_token_users] 
token1 = joe

就这样！ 如果您有CouchDB 1.2或更高版本，您还可以在_users数据库中的用户文档中定义OAuth凭据：

{
    "_id": "org.couchdb.user:joe",
    "type": "user",
    "name": "joe",
    "password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
    "salt": "4e170ffeb6f34daecfd814dfb4001a73"
    "roles": ["foo", "bar"],
    "oauth": {
        "consumer_keys": {
            "example.org": "sekr1t",
            "consumerKey2": "key2Secret"
        },
        "tokens": {
            "token1": "tokensekr1t",
            "token2": "token2Secret"
       }
    }
}

现在，当我们为用户joe设置OAuth凭据时，让我们开始复制。 要让CouchDB使用OAuth凭据，我们需要扩展source或target字段，具体取决于哪一方将授权我们的用户：

{
    "source": "mailbox",
    "target": {
        "url": "https://secure.example.org/mailbox",
        "auth": {
            "oauth": {
                "consumer_secret": "sekr1t", 
                "consumer_key": "example.org", 
                "token_secret": "tokensekr1t", 
                "token": "token1" 
            }
        } 
    } 
}

并将此数据POST到_replicate资源或为_replicator数据库创建文档。 复制将使用SSL协议加密从本地服务器启动到远程secure.example.org ，所有操作都将通过登录joe进行远程用户操作。

总结：SSL和OAuth的组合不仅可以保护传输的数据（不仅是用户凭证），还可以保证目标服务器不是伪造的，还可以保护真实用户登录名和密码免于意外泄露，控制消费者来源（例如，如果example.org将被泄露，我们只能删除他的消费者令牌，但不能强迫用户更改他的密码）并签署针对MiTM攻击的额外保护请求。

更新 ：对于您的情况，常规SSL证书例程是可以的：您需要创建自己签名的个人证书，并让客户设置以便与CouchDB进一步协作。 CouchDB方面唯一需要的是在处理连接之前验证证书。 但请注意，自定义个人SSL证书安装可能并非易事，特别是对于移动客户端。

对于OAuth方面，CouchDB 可能会使用RSA-SHA1身份验证方法，该方法使用某种个人证书进行保密。 但是，您需要首先修补源以解锁此方法 - 默认情况下禁用它。