I'm developing some iOS apps and I'm downloading/uploading data which are very sensitive.
I'm using AFNetworking to do that requests and my question is simple:
I reach only 3 different certificates in all the app, can I custom AFNetworking's layer to accept only these 3 certificates?
The aim of this manipulation will be to avoid "Man To the Middle" attacks and so avoid injection and/or retrieval of any additional information during the HTTP exchanges.
All AFNetworking operations inherit from AFURLConnectionOperation, which defines a block called authenticationChallenge. Setting this block on your operations will define how AFNetworking responds to the NSURLConnectionDelegate method connection:didReceiveAuthenticationChallenge:. Specifically, you will want to inspect challenge.proposedCredential.
If you don't want to set this block on every operation, you could also subclass the operation type you're using (like AFJSONRequestOperation, for example), and override connection:
willSendRequestForAuthenticationChallenge: with the behavior you want.
Related
I am using AFNetworking for my client and server communication. I want to make a wrapper on top of AFNetworking so that I can set common header and extra information for all the HTTP requests. Basically all my HTTP request will go through one layer to AFNetworking. It will make my client server communication easier and I will be able to include any kind of data with all the http request at any point of time. What will be the best way to do it?
As example I want to send token, network status, user info etc.
More specifically:
I want to include some common info with all the request like network info, user info, token. Now its really difficult to change in each and every request. So I want to design in such a way that all the http call will go through one path and I can send anything with AFNetworking HTTP Request without touching all the file.
You should create one separate class that manage all the network related calls. You should subclass NSObject and make a class with different required methods that you need. Import your AFNetwotking in this class and use this class in whole project when needed to make network call!
I am finding that when my iOS device automatically configures a proxy, all of my NSURLSessions are using it for downloads/uploads/requests. This becomes a problem when I'm trying to make those requests from other devices on the same local network. I need to disable the proxy that the device autodetects for NSURLSession.
Every post everywhere indicates how to set the proxy dictionary, however, I can't find anywhere how to make sure the NRURLSession doesn't use a proxy.
Any help would be appreciated!
If you provide an empty proxy dictionary when creating the session configuration, NSURLSession should ignore the system-provided proxies in all sessions created with that session configuration.
If you're trying to override it for something where you didn't create the session (e.g. third-party frameworks, web views, etc.), you can usually solve that by creating and registering (globally) an NSURLProtocol that takes the requests and reissues them in your own session (adding some custom header so that you don't keep reissuing the same request in an infinite loop). There are some basic examples of writing custom protocols on Apple's website.
We're making calls to an API to get JSON data using AFHTTPRequestOperationManager.
Currently, we are instantiating a new AFHTTPRequestOperationManager for each request. We're considering instantiating just a single AFHTTPRequestOperationManager and reusing it across requests.
What are the trade-offs?
There are several reasons why AFHTTPRequestOperationManager per domain is a handy pattern:
1) You save the resources of creating a new manager for each request which can create significant memory pressure
2) Having just one reference to a manager allows you to easily manage all the network requests in your app. For example, when a user logs out you may want to cancel all requests. With just one manager you can easily access the operation queue and cancel them all at once.
3) Related to #2, having one instance allows you to manage the configuration for all your requests at once. For instance adding authorization headers or configuring custom parsers. These could of course be done before every request but it adds unnecessary complexity.
I have an IOS6 app, that connects to a REST API to fetch some data.
I use NSURLConnection sendSynchronousRequest in my data fetcher class, and I call its methods by GCD async pattern with blocks from my controller classes. So far so good.
My problem, that I change the API endpoint to https, its certificate is self-signed (I know its secure problems etc, but it is out of question for now).
By using sendSynchronousRequest I can't bypass this problem, because to bypass it, I need to set delegate for NSURLConnection, but in case of sendSynchronousRequest I cant' set delegate, delegate methods just called in case of async calls.
I don't like async request calling, I adore this GCD/sync call pattern very much, it works like a charm, it simple and clear.
So how can I make calls to a https api endpoint by GCD and , NSURLConnection sendSynchronousRequest that bypasses untrusted certificate problem?
Thanks to all!
You answered your question already yourself:
By using sendSynchronousRequest I can't bypass this problem, because to bypass it, I need to set delegate for NSURLConnection, but in case of sendSynchronousRequest I cant' set delegate, delegate methods just called in case of async calls.
You should really get used to the asynchronous style. The approach with a synchronous call within a dispatch_async call is suboptimal to say the least.
The method sendSynchronousRequest is for beginners and toy apps. IMHO, Apple should really deprecate this method and remove it in the next iOSs.
The method sendAsynchronousRequest:queue:completionHandler: is for demonstration purposes, sample apps, prove of concept, and very simple requests not using authentication and https.
Finally, using the asynchronous style with implementing the delegates is for "serious" and release apps. Any serious app should use https when talking to a dedicated server, unless the server is public and does not support https.
Once your have switched to asynchronous style, there might be an answer to your actual question. However, there is no need to bypass a certificate - rather you will use the certificate as it is used in the release app.
As a novice iOS developer, I am trying to understand some concepts related to the callback mechanisms in iOS.
My model makes HTTP requests through NSURLRequest to a backend rest service. The model has several methods which corresponds to the methods in the service. NSURLRequest is based on the delegate pattern, which means that I receive a common callback for all of the service calls. Then, my model has to find out which service call the callback is related to, so that I can send an appropriate update event to the controller. This is awkward since I have to maintain som state in the model to remember which call I made the last time (which is very impractical in the case of concurrency), or interpret the payload in the HTTP response.
I would wish that NSURLRequest would support the target-action pattern, so that each of the requests could decide which callback method to use. Is that possible? Am I missing something here?
If target-action is not available in the framework, what are the best practices to solve this?
The way to do this is to use NSURLRequest with NSURLConnection. If you check out the docs for NSURLConnection, they will tell you that you need to implement the callback methods in the NSURLConnectionDelegate protocol, and will give you details.
That page also points to several examples, with sample code.
You can also check out the URL Loading System Programming Guide at developer.apple.com, which will give you additional information on how these classes are intended to be used.