Re: Problems with authenticated background downloads involving a 301 redirect
Re: Problems with authenticated background downloads involving a 301 redirect
- Subject: Re: Problems with authenticated background downloads involving a 301 redirect
- From: Andreas Fink <email@hidden>
- Date: Wed, 23 Jul 2014 23:21:58 +0200
Am 23.07.2014 um 22:56 schrieb Scott Hancher < email@hidden>:
This took some time to figure out how to decipher the initial request and redirected request. I did manage to get Charles Proxy to decipher the data for me, but it didn't work until I pulled this line:
_configuration.TLSMinimumSupportedProtocol = kTLSProtocol12;
The TLS Protocol 1.2 is where forward secrecy comes into place. Hence its no surprise that decryption wont work anymore. But it depends on how which level Charles Proxy is proxying. With this line in place I kept getting an SSLHandshake failed problem.
Now that I can trace the requests, I've determined that this is NOT specific to background downloads. Within the initial request, we add an 'Authorization' header to the request. When our server redirects via a 301, the subsequent redirected request does not include this 'Authorization' header. I added an innocuous foo:bar header just to see if all headers were getting stripped, but foo:bar survived the redirect. This was working for foreground downloads, because we implement the delegate method, URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler: and carry over the 'Authorization' header from the original to the redirected request. We have no such facility to do so for background downloads.
Is this a known issue? What do you suggest?
Authentication always works the way that no authentication header is passed and the server rejects and asks for authentication with a 301. This would pop up an authentication header in the browser.
If the original URL is redirected to a second URL, then the authentication realms might not be the same so OS X is correct in not sending authentication headers to the redirected server. If that server would not like the request and requests authentication, he answers with a 301 and then your URL would be resent with authentication. Authentication information can be held in cache for a specific realm and thus sent automatically but this is only valid in the same URL path. As you are redirecting from Server A to Server B, the cached authentication information for A is not valid for B.
So my answer would be that OS X is doing the correct behaviour. You could simply redo the URL to the redirected host directly.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden