标签: http-digest

我必须用Node.JS编写一些代码来获取API文档,但是我在最近几天尝试了我在网上找到的所有解决方案(包括Stack当然)都没有成功...

我的API使用HTTP Digest Auth,这就是问题,我能够连接,这不是什么大问题,但每次我得到相同的回报:

Got response : 401
HTTP Digest Authentication required for "api.example.com"

你可以在没有auth的情况下显示我的基本代码!因为我做了所有的尝试后我不知道自己能做什么:

var http = require('http')

var options = {
    host: 'api.example.com',
    path: '/example/1.xml',
};

var request = http.get(options, function(res){
    var body = "";
    res.on('data', function(data){
        body += data;
    })
    res.on('end', function(){
        console.log('Got response : ' + res.statusCode);
        console.log(body);
    })
    res.on('error', function(e){
        console.log('Got error : ' +e.message);
    });
});

我最后一次尝试是使用这个模块https://npmjs.org/package/request但是每次我得到401时他都不会工作!

有关更多信息,我能够使用Ruby,Python,php和Java连接并获取我需要的API信息,因此我确信我的API运行良好,并且我传递的信息是正确的.我使用Node v0.10.11的最后一个稳定版!

如果有人可以帮助我或找到解决方案,我会很高兴.

编辑:我将使用模块Mickael/request添加有关我的测试的一些细节

第一次尝试 :

var request = require('request')

var options = …

我有一个应用程序与使用HTTP摘要身份验证的服务器通信.

在我看来,iPhone中的"会话"管理对于我们的开发人员来说是相当"黑盒子".是不是我们无法看到框架如何处理/持久化http会话？

如果我只是在这里昏暗,有人会解释如何在iPhone上处理HTTP摘要身份验证吗？

我的基本操作是:

• 向安全网址发出请求
• 服务器发送401
• 客户端创建并保留凭证,并将其传递回服务器
• 服务器验证凭证,验证完成请求,否则发送另一个401.
• 发出后续请求以保护网址
• 服务器再次请求授权........

这适用于单个请求,但如果我发出其他后续请求,则服务器再次请求授权.服务器已经为特定用户持久保存了会话,但是iPhone由于某种原因没有在同一会话中发出请求...因此,服务器必须抛弃认证对象并在每次客户端创建一个新对象向安全网址发出请求.

我确定这不是正确的行为.

如果我们看一下浏览器在这种情况下的行为:

• 浏览器从安全URL请求数据
• 服务器发送401
• 浏览器提示用户输入凭据,持久保存,将其传递给服务器
• 服务器验证凭证,如果验证则返回数据,否则发送另一个401.
• 由于浏览器管理会话,因此不会提示对安全URL发出的后续请求提供凭据.

我正在创建NSURLCredential并将其保留在NSURLCrendtialStorage中.然后,当应用程序收到'didReceiveAuthenticationChallenge'时,我从存储中检索凭证并将其传回,如果不存在(在第一个请求中),则创建凭证.

任何帮助将不胜感激.谢谢.

好吧,这可能听起来像一个奇怪的问题.在跳我之前请仔细阅读好吗？;-)

想象一下这种情况:

1. 我们有一个服务器和一个客户端.
2. 他们使用SSL连接.
3. 客户端使用密码在服务器上创建帐户
4. 但是,他实际通过网络传递给服务器的是密码的哈希(+盐)(不是密码)
5. 服务器在DB中保存此接收的密码哈希值(使用盐哈希)
6. 在登录时,要进行身份验证,用户重新发送密码哈希值(不是密码!).

好的,是的,我意识到这听起来很奇怪.是的,整个会话都在SSL中,所以你可以发送密码明文.是的,我意识到可以安全地存储明文密码.

以下是我的观点:对我们的业务来说,真实地说"我们永远不会知道您的密码"是​​有用的.

注意我不是说"我们不以明文形式存储您的密码",但我们真的,从来没有,知道它; 你永远不会把它给我们.

(想要这个的原因是不相关的,足以说用户的密码用于其他东西,例如文件加密).

是的,我意识到你可能会说正常的做法是"在你进行散列时,密码只能在内存中以明文形式显示5ms",但这更多是关于否定性.即,我们可以说100%我们甚至没有收到您的密码.

好的,这就是问题所在:

• 以前有人做过或听说过这种事吗？

• 这样做有什么安全隐患？

我很难看到一个缺点.例如:

• 没有重播攻击(因为会话使用SSL加密,攻击者无法看到哈希)
• 无法查看数据库,因为哈希本身就是哈希...,哈希

好的,你现在可以跳我:)

想法,欢迎评论.

谢谢,

约翰

更新:只是想澄清:我并不是说这在某种程度上改善了身份验证过程的安全性.但是,它允许用户的"真实"密码保持秘密,即使是从服务器.因此,如果真实密码用于加密文件,则服务器无权访问.

我完全满足于我想要这个的原因,问题是它是否会妨碍身份验证过程的安全性.

我正在使用FOSUserBundle配置Symfony2应用程序以使用http_digest身份验证.这是Symfony 2.1.0-BETA2.

在security.yml,我简单地切换出来http_basic了http_digest,并添加所需的key属性.其他一切都是一样的.

有效的相关配置:

firewalls:
    main:         
        pattern: ^/
        anonymous: ~
        form_login: false            
        provider: fos_user_bundle
        http_basic:
            realm: "Example Realm"

相关配置不起作用:

firewalls:
    main:         
        pattern: ^/
        anonymous: ~
        form_login: false            
        provider: fos_user_bundle
        http_digest:
            realm: "Example Realm"
            key: "%secret%"

正如你所看到的,唯一的区别是切换出来http_basic的http_digest.更改key属性的值似乎没有区别.

使用in_memory提供程序时,http_digest工作得很好.只有在使用fos_user_bundle提供商时才会出现此问题.

通过工作,我的意思是在使用时http_basic,接受有效的用户凭证.使用http_digest相同的有效用户时,不接受详细信息,并重新显示浏览器的默认http验证提示.

在安全配置更改之间,我清除dev和prod缓存,清空浏览器缓存并关闭浏览器.

配置中是否缺少一些关键的东西？

更新

我已经记录了一次成功的http_basic尝试和一次不成功的http_digest尝试,并将日志分开.

两个日志都是相同的,包括Doctrine记录用于身份验证的SQL查询的位置.

在http_digest日志中的身份验证查询之后是以下行:

security.DEBUG: Expected response: '3460e5c31b09d4e8872650838a0c0f1a' but received: '5debe5d0028f65ae292ffdea2616ac19'; is AuthenticationDao returning clear text passwords? [] …