SSL pinning revised #878

wants to merge 2 commits into


None yet

3 participants

  • As discussed in #877, AFNetworking will now trust each pinned certificate and its derived certificates (a91f40b).
  • I think all operations enqueued to an AFHTTPClient should inherit the default pinning mode if not explicitly set otherwise. Thats what the method swizzling in 05a991b is for. There are tons of places in my code where I don't use -[AFHTTPClient HTTPRequestOperationWithRequest:success:failure:] to take advantage of the specialized completion handler of each AFHTTPRequestOperation subclass. In these cases, I need to manually enqueue each created operation.

I wonder if 05a991b is a little to much since the pinning mode is already being set in HTTPOperationWithRequest:success:failure:? Do you think it will be a common use case to need to change the pinning mode on the fly with operations already queued up? I feel like the 99% use case would be a setup step when creating the AFHTTPClient, and you can assume that whenever the operation is created, it gets the current pinning mode set on the client. If you for some reason you need that to change, you would need to cancel your operations and recreate them with the new pinning mode set.


Ouch. I wasn't aware that for example -[AFHTTPClient HTTPRequestOperationWithRequest:success:failure:] already returns a JSON object for AFJSONRequestOperation. But I still think it makes sense because if you create an AFHTTPRequestOperation and enqueue it manually to an AFHTTPClient instance, the operation should inherit the default pinning mode.


If you create an operation that way, you also miss out on everything else that is set by default for the client (i.e. auth, request headers, parameter encoding, etc). I would expect this property to behave exactly the same as the others.


Maybe auth, request headers, parameter encoding, etc should inherit these values as well?


I would imagine that @mattt would prefer to keep the library as light weight as possible, and the swizzling here is overkill.

If you create your own operation outside of the built in client methods, it should be on the developer to configure that operation to their hearts content :)


light weight is a good point but setting the default values on enqueuing operations still feels kind of right to me. :S

I mean you could still use your custom NSOperationQueue not managed by AFHTTPClient or directly calling [httpClient.operationQueue addOperation:...]. In these two cases I would expect no default values being applied to the operation, but for -[AFHTTPClient enqueueHTTPRequestOperation:], I would.

jparise commented Mar 27, 2013

Perhaps it makes sense to split this into two separate pull requests? a91f40b is useful on its own, and it sounds like 05a991b is inviting more general discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment