new Proxy Authentication alert since iOS 10.1.1

I do have a very strange problem since iOS 10.1.1. In my App I've configured a proxy for the NSURLSessionConfiguration object so the App can use the proxy and there does not need to be a proxy configured in the WLAN settings of the system.


The proxy requires authentication. So the App will eventually ask for user name and password when the delegate method "URLSession:task:didReceiveChallenge:completionHandler:" and makes sure that the request can continue.


This worked fine before and still does under iOS 10.1.1, but since updating to iOS 10.1.1 the iOS itself opens an alert view stating the a proxy authentication is required and gives the user the choice to do this "later" or directly go to the system settings. This alert box is completely silly, because the system settings do not have any proxy configured for which the user can enter any credentials. Also this alert view is shown by the iOS even before(!!) the above "didReceiveChallenge" delegate method of NSURLSession is called. So its impossible to avoid this silly system alert, because the App does not get a chance to provide the credentials before the iOS displays this alert.


Does anyone else seeing this and knows how to fix this?



BTW: When this iOS alert appears, I do get the following in the console of XCode:

*** WARNING: CFMachPortSetInvalidationCallBack() called on a CFMachPort with a Mach port (0x2a07) which does not have any send rights. This is not going to work. Callback function: 0x18e5967d8


This all seems to be new since iOS 10.1.1

Replies

This is not the first report I’ve seen of problems like this, although the fact that it’s only now cropping up on 10.1.1 is weird; the other folks I’ve talked to with issues like this saw the problem on much earlier OS releases (s. 640586739).

The NSURLSession architecture is designed to handle this sort of situation well. Authentication challenges, including proxy authentication challenges, should go to the session delegate which can handle them as it likes. If it resolves the challenge with

.performDefaultHandling
, built-in infrastructure (like proxy password alerts) should kick in.

Alas, this does not always work as expected. IMO such problems are bugs and you should file them as such. Please post numbers of any bugs you file, just for the record.

Based on your other post I’m assuming that you’re doing this in an NSURLProtocol subclass underneath a web view. Is that correct? If so, does the problem reproduce outside of that context, that is, if you issue the same request by calling NSURLSession directly from a test app that doesn’t include your NSURLProtocol subclass?

Also, what authentication schemes (Basic, Digest, and so on) does your proxy support?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I've noticed this only since the very last iOS 10.1.1 update. This does not mean that this issue isn't present before, but it might show up only under specific circumstances which my App did not trigger.


You are right, this occurs within requests made with NSURLSession, which were initiated from UIWebView through NSURLProtocol. The problem should be unrelated to NSURLProtocol, because the request is made by NSURLSession and it should not matter from where NSURLSession gets its network request, because it is running independantly. But I'll check if I can find a way to reprodude this without NSURLProtocol. But this can be very difficult, because the issue occurs only for certain requests wehn loading certain web sites, so the origin for these requests would be the web engine. For WKWebView it would be impossible to reroute the network through a App-specific proxy at all, and for UIWebView this would only work when using NSURProtocol which allows to reroute the reuests through a NSURLSession which has a proxy confgured. So you see, everything relies on NSURLProtocol right now...

I've now filed a bug report (#29138331). The problem has nothing to do with the web engine or NSURLProtocol. I can reproduce it with a simple request via NSURLSession, so no NSURLprotocol or UIWebView/WKWebView needs to be involved.

I've now filed a bug report (#29138331).

Thanks.

The problem has nothing to do with the web engine or NSURLProtocol. I can reproduce it with a simple request via NSURLSession, so no NSURLprotocol or UIWebView/WKWebView needs to be involved.

OK, that’s a useful data point.

Finally, earlier I asked:

Also, what authentication schemes (Basic, Digest, and so on) does your proxy support?

I’m still interested in the answer to that.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The proxy seems to use the "Basic" authentication scheme in my test cases (at least this is the information I get from the "protectionSpace" parameter of the "challenge" I get from NSURLSession).

The proxy seems to use the "Basic" authentication scheme in my test cases …

One potential workaround here is to add a

Proxy-Authorization
header to the recursive requests issued by your NSURLProtocol. This isn’t a particularly nice workaround — as mentioned in the docs, these headers are ‘owned’ by NSURLSession — but it might work.

This won’t work for Digest because you need to get the challenge to form the

Proxy-Authorization
header.

I’ve also seen reports of this technique working on earlier systems but failing on iOS 10.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the suggestion to use the additional headers that can be defined for the NSURLSession. It seems that this would solve my problem for now.

It seems that this would solve my problem for now.

Cool.

Two things:

  • Make sure you test this properly before committing to it as a solution; as I mentioned earlier, I’ve had a least one developer report that this trick has become unreliable starting with iOS 10 )-:

  • Don’t forget to file an enhancement request for explicit proxy support in WKWebView. It’s important that the WKWebView team hear about all the things that are keeping folks on UIWebView. I’d also appreciate you posting the bug number so that I can add it to my own personal watch list.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Having same issue, but failing on ios10.1.1 ios 9.2.1 ios 8.3 in my test cases.

The proxy use the "Digest" authentication scheme and this occurs only within HTTPS requests