I’m trying to standardize my handling of authentication challenges such that the same code paths can be used for handling/resuming requests that fail because of standard HTTP authentications (Basic Auth, etc.) and with less standard failures. 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).
For context, the types of scenarios I run into are for example situations where authentication for a web service is handled not at the HTTP protocol level but inside the network content. For example it is common with XMLRPC based blogging APIs for credentials to be embedded in the XML cargo of the request itself, and for an authentication failure to be indicated in the body of a response (with 200 status code!). I envision that my code that handles such clunky authentication interfaces would put together its own NSURLAuthenticationChallenge with a protection space that is discernible by the client, and that will then also be obvious when called back that it is a type of authentication that should be embedded in the content in this way and not set on the HTTP request itself. So my question is, am I asking for trouble by trying to expand upon NSURLProtectionSpace to define my own space? Most of the protection space attributes that I have considered tweaking are just NSString values, but I don’t know if there are subtle behavioral changes that will occur if I try to e.g. initialize with an authentication method that is not known to the system. It’s also not clear if I should feel safe in e.g. subclassing it to provide additional information about what the protection space pertains to. It feels bolted on, but it seems valuable to have a single authentication callback chain. I also wonder, for example, how secondary authentication information such as requests for two-factor authentication tokens should be expressed in terms of NSURLProtectionSpace. In summary I want to use NSURLProtectionSpace consistently as an object that expresses whatever authentication challenge I may receive, but it seems relatively limited in scope to authentications that are expected to occur strictly at the protocol level. I would appreciate any thoughts or pointers people may have about stretching the NSURLProtectionSpace facility beyond its usual scope. Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to [email protected]
