0
で作業していない私は以下のようにセッションデリゲートでカスタムプロトコルを実装した -認証チャレンジは、カスタムプロトコル
- (void)startLoading {
NSMutableURLRequest *mReq = [self.request mutableCopy];
NSURL *url = [[self request] URL];
NSURLSessionConfiguration *config = [NSURLSessionConfiguration defaultSessionConfiguration];
...
...
if(!_mySession) {
_mySession = [NSURLSession sessionWithConfiguration:config
delegate:self
delegateQueue:[NSOperationQueue mainQueue]];
}
.....
}
- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler{
NSURLAuthenticationChallenge* challengeWrapper = [[NSURLAuthenticationChallenge alloc] initWithAuthenticationChallenge:challenge sender:[[CustomAuthChallengeWrappers alloc] initWithSessionCompletionHandler:completionHandler]];
if(self.client){
if([self.client respondsToSelector:@selector(URLProtocol:didReceiveAuthenticationChallenge:)]) {
debugLog("auth-challenge");
[self.client URLProtocol:self didReceiveAuthenticationChallenge:challengeWrapper];
}
}
}
クライアントはNSURLConnectionを使用している場合、それが正常に動作しています。クライアント側でNSURLSessionを使用すると、Authチャレンジが転送されますが、カスタムプロトコルでは返されません。 チャレンジラッパーは、次のリンクで実装されています： NSURLProtocol Challenge wrapper
NSURLSessionには何も足りませんか？
チャレンジ送信者がそのセレクタに応答しないケース、またはself.clientがnilであるケースは処理していませんが、それはおそらく問題ではありません。このラッパーはそれを行う奇妙な方法のようです。通常、NSURLProtocolはチャレンジ送信者であり、任意の「ラッパー」クラスではありません。通常、これらのメソッドを自分のプロトコルに実装します。私はそれが問題の原因だとは思っていませんが、おそらくデバッグをより難しくしています（意図しない）。 – dgatwood
最も問題になるのは、他の 'NSURLSession'が奇妙なことをしていることです。挑戦に正しく反応しないのですが、確かに知るためには他のコードを見なければなりません。また、プロトコル処理の無限の再帰に陥っていないことを確認する必要があります。プロトコルが以前に見た要求を正しく拒否していることを確認してください。カスタムヘッダーを設定するか、 '[NSURLProtocol setProperty：forKey：inRequest：]'を使用してください。 – dgatwood
NSURLProtocolチャレンジ送信者の別の問題が期待通りに機能しません。それはクライアントに転送されますが、クライアントはNSURLProtocolではなく直接サーバーにヒットします。サーバーは異なるパスから来ているため、サーバーはそれを拒否します。ラッパー以外のオプションはありません。また、私は無限再帰に就いていません。同じコードは、クライアントサイドでNSURLConnectionと完全に動作します。 – sona