0

I have implemented custom protocol with session delegate as below -

- (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];
            }
    }
}

If client uses NSURLConnection, it is working fine. If I use NSURLSession on client side, its forwarding the Auth challenge but not receiving back in custom protocol. Challenge wrapper is implemented as per this link: NSURLProtocol Challenge wrapper

Am I missing anything for NSURLSession?

Community
  • 1
  • 1
sona
  • 11
  • 2
  • You aren't handling the case where the challenge sender doesn't respond to that selector or where self.client is nil, but that's probably not the problem. This wrapper seems like an odd way of doing it. Normally, your NSURLProtocol would be the challenge sender, not some arbitrary "wrapper" class. And normally you would implement those methods in your protocol. I doubt that's the cause of the problem, but it probably makes debugging more challenging (pun intended). – dgatwood Sep 07 '16 at 07:00
  • The most likely issue is that the other `NSURLSession` is doing something odd, like not responding to the challenge correctly, but I'd have to see the other code to know for sure. You should also check to make sure you aren't getting into an infinite recursion of protocol handling—make sure that your protocol correctly rejects any requests that it is seen previously, e.g. by setting a custom header or by using `[NSURLProtocol setProperty:forKey:inRequest:]`. – dgatwood Sep 07 '16 at 07:03
  • Another problem with NSURLProtocol challenge sender doesn't work as expected. It forwards to the client but client directly hits the server not the NSURLProtocol. Server rejects it because its came from different path. Don't have option other than wrapper. Also I am not running into infinite recursion. Same code works perfectly with NSURLConnection at client side. – sona Sep 07 '16 at 08:14
  • I'm not sure why there would be any difference between using that wrapper class and passing `self` as the sender and implementing those same methods in your protocol class (which is the intended usage).... What do you mean when you say that the client hits the server? Do you mean that the client callback data is getting somehow sent directly to nsurlsessiond? – dgatwood Sep 08 '16 at 06:20

1 Answers1

0

Just to update it is working fine with iOS 10 and xcode 8 beta version. Looks like there was some problem in iOS 9.3 which has been fixed in this release.

sona
  • 11
  • 2