NSURLCredentialStorage 默认凭据未自动使用 [英] NSURLCredentialStorage default credential not used automatically

查看:62
本文介绍了NSURLCredentialStorage 默认凭据未自动使用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在从 NSURLConnection 切换到 NSURLSession 以进行我的应用程序通信,并且在此期间,我尝试从委托身份验证转向使用 NSURLCredentialStorage.我已经移动了代码,但是尽管在应用启动时在 sharedCredentialStorage 上设置了 defaultCredentials,但我在委托上调用了 -URLSession:task:didReceiveChallenge.

I'm switching from NSURLConnection to NSURLSession for my app communications and, while I'm at it, trying to move from delegated authentication to utilising NSURLCredentialStorage. I've moved over the code however I'm getting -URLSession:task:didReceiveChallenge being called on the delegate despite having set defaultCredentials on the sharedCredentialStorage when the app launches.

根据以下记录的消息,保护空间是相同的(我在设置凭据时创建的空间和 NSURLAuthenticationChallenge 传递的空间):

The protection spaces are identical (the one I created when setting up the credentials and the ones passed by the NSURLAuthenticationChallenge) as per the below logged messages:

Register credentials for: <NSURLProtectionSpace: 0x162227c0>: Host:192.168.1.99, Server:https, Auth-Scheme:NSURLAuthenticationMethodDefault, Realm:192.168.1.99, Port:23650, Proxy:NO, Proxy-Type:(null)
Unexpected authentication challenge: <NSURLProtectionSpace: 0x1680ee40>: Host:192.168.1.99, Server:https, Auth-Scheme:NSURLAuthenticationMethodDefault, Realm:192.168.1.99, Port:23650, Proxy:NO, Proxy-Type:(null)

在 didReceiveChallenge:(NSURLAuthenticationChallenge*)challenge 委托方法中:

and during the didReceiveChallenge:(NSURLAuthenticationChallenge*)challenge delegate method:

po [[NSURLCredentialStorage sharedCredentialStorage] defaultCredentialForProtectionSpace:[challenge protectionSpace]]

结果

<NSURLCredential: 0x1680ff00>: thecorrectusername

https://stackoverflow.com/a/501869/563905 表示当服务器响应 401挑战,NSURLConnection(这是一个 NSURLSession 问题吗?)首先检查授权的标头(没有任何设置),然后咨询 NSURLCredentialStorage 以获取保护空间的凭据.

https://stackoverflow.com/a/501869/563905 indicates that, when the server responds with a 401 challenge, the NSURLConnection (is this a NSURLSession problem?) first checks the headers for Authorization (there aren't any set) and then consults NSURLCredentialStorage for credentials for the protection space.

我只是不明白为什么会调用 didReceiveChallenge 委托?当我没有设置委托方法时,NSURLSession 只是在没有任何凭据的情况下重新发送请求......我很难过......

I just don't understand why I'm getting the didReceiveChallenge delegate being called? When I don't have the delegate method set the NSURLSession simply resends the request without any credentials... I'm stumped...

我已经向 didReceiveChallenge: 方法添加了手动凭据处理,尽管只使用了一个 NSURLSession,它还是会为每个请求触发.

I've added manual credential handling to the didReceiveChallenge: method and it's being triggered for every request despite only a single NSURLSession being used.

推荐答案

我遇到了同样的问题,我的 URLSession 不使用存储的凭据.然后我阅读了 NSURLSession 的参考文档.基本上它说的是,如果您正在实现自定义委托,那么当委托方法被调用时,您必须自己处理所有事情.换句话说,保存凭据是成功的一半.每次服务器需要身份验证时,您都会收到质询,因此在 didReceiveChallenge 方法中,您现在必须手动提取要使用的凭据并将它们传递给完成处理程序.让我知道这是否有意义.

i was just having the same problem where my URLSession would not use the stored credentials. Then i read the reference docs for NSURLSession. Basically what it says is that if you're implementing a custom delegate then you have to handle all the stuff yourself when the delegate methods get called. In other words saving the credentials is half the battle. You will be receiving the challenge every time the server requires authentication so in the didReceiveChallenge method you now have to manually extract the credentials to use and pass them to the completion handler. Let me know if that makes sense.

这篇关于NSURLCredentialStorage 默认凭据未自动使用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆