Re: Using NSURLProtectionSpace for undocumented/unusual spaces
Re: Using NSURLProtectionSpace for undocumented/unusual spaces
- Subject: Re: Using NSURLProtectionSpace for undocumented/unusual spaces
- From: Daniel Jalkut <email@hidden>
- Date: Tue, 24 Mar 2015 08:08:46 -0400
Thanks, Quinn! You’ve confirmed my paranoia about exploiting NSURLProtectionSpace et. al. beyond their intended purposes.
A more generalized "suspension callback" seems in order anyway. It would cover potential needs to e.g. demand 2nd-factor authentication details, and could also cover other cases where asynchronous suspension is in order e.g. for prompting about handling of redirect behavior for POST requests.
Daniel
> On Mar 24, 2015, at 5:57 AM, Quinn The Eskimo! <email@hidden> wrote:
>
>
> On 23 Mar 2015, at 17:43, Daniel Jalkut <email@hidden> wrote:
>
>> To that end, I’m curious about customizing NSURLProtectionSpace such that I would issue my own authentication challenges (mimicking the URL loading system’s automatic issuance of challenges).
>
> I wouldn't go down this path. Rather, I'd wrap the built-in authentication challenge type with your own type and allow that type to specify your custom protection space if necessary. That way you can still have a single code path in your app, but you don't have to make any assumptions as to how well the system will handle unusual protection spaces.
>
> My specific concern here relates to the interaction between the Foundation-level API classes you see and the CFNetwork level C++ classes that do all the heavy lifting here. My experience is that these interactions are not smooth [1]. For example, prior to the introduction of -[NSHTTPURLResponse initWithURL:statusCode:HTTPVersion:headerFields:], some folks tried constructing an NSHTTPURLResponse with their own status code and headers by subclassing NSHTTPURLResponse and overriding the -statusCode and -headerFields methods. This does not work because NSHTTPURLResponse is an Objective-C wrapper around a CFNetwork object, and overriding these Objective-C methods has no impact on CFNetwork-level callers.
>
> Share and Enjoy
> --
> Quinn "The Eskimo!" <http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>
> [1] Back in the day, when NSURLConnection was first released, its core implementation was in Objective-C and all this stuff worked a lot more smoothly.
>
>
> _______________________________________________
> 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
_______________________________________________
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