We know that https is different with http by encrypting the content over http tunnel, simply speaking.
For the web browser, since user accept the permission from the popup alter dialog, the browser will get the keys from installed certificates and do the job so on.
For iOS client development, how to handle the digital certificate, and get the public key and encrypt the content via the public key ? thanks,
( By the way, AFnetworking is the famous open source project for iOS developer to handle the http stuff, but seems like that it does not handle the https. (correct me if wrong ) )
NSURLConnection and NSURLSession are the underlying classes used by all HTTP iOS libraries. These two classes does the HTTPS handling for you. Nothing for you to worry about.
Then, you can use libraries as AFNetworking or Hermod that work on top of these basic iOS classes.
AFNetworking is the most popular one.
Hermod is my preferred. It is a new library built on top of AFNetworking and its API is much simpler and easy to use. Also, it has built-in support for OAuth.
It's already done for you.
AFnetworking, the underlying iOS network library it's built on, NSURLConnection and pretty much every networking library (eg, ASIHTTP, etc) all handle the https protocol for you transparently.
Indeed, the very first line on the front page of the AFNetworking github page is an https example:
NSURL *url = [NSURL URLWithString:#"https://alpha-api.app.net/stream/0/posts/stream/global"];
Related
I just added SSL to my backend framework (Django REST API) and I want my iOS application to talk to it. Do I have to do anything differently on the iOS side of my project? How do I tell Alamofire to encrypt the data its sending? Or Does it happen automatically?
The only difference is using https instead of http. I have the same setup at work, and originally thought I was going to have to delve into certificates. I started heading in that direction and then realized all my requests worked as soon as I stuck the "s" on the end.
I will say, while using NSStream, you do have to setup the stream to handle the certificate. I am doing this in another application, but that is below the URLRequest class. I am unsure of how low level Alomofire actually delves, but it will definitely handle everything you desire without doing anything differently.
Just update URLs inside your app to use "https" and you are done.
I've read about push-promise in HTTP/2 specs and several other tutorials, and have an idea as a concept.
I've read here in SO why bundling won't be as relevant in upcoming days. So, if I have to incorporate push promise into applications, where is the ideal place to do this. Should it be just before redirecting to the view from the Action method? Or, in the script in the view? As far as I've searched I couldn't find any examples.
Please someone share their experience implementing in the real code. Does it seem like an overhead if you have to support both the protocols?
Also, if I'm using IIS 10, then is there any configuration changes that I should do to support both protocols? [As far as I've read, we don't have to. But always better heed to some experts.]
So, if I have to incorporate push promise into applications, where is the ideal place to do this. Should it be just before redirecting to the view from the Action method? Or, in the script in the view?
I did it in the controller action method while experimenting, but if you have common resources you may want to move it somewhere more fundamental/shared in the pipeline. Anywhere that has access to the HttpResponse object should work. As I noted here, you'll want to use the PushPromise overload that takes in an HTTP method and headers if what you're pushing will vary based on any request headers, e.g. accept-encoding (compression).
Does it seem like an overhead if you have to support both the protocols?
Also, if I'm using IIS 10, then is there any configuration changes that I should do to support both protocols?
You do not need to do anything explicitly to support both protocols; IIS will take care of it. Per David So of Microsoft, "provided the client and server configuration supports HTTP/2, then IIS will use HTTP/2 (or fallback to HTTP/1.1 if not possible)". This is true even if you're using server push: "If the underlying connection doesn’t support push (client disabled push, or HTTP/1.1 client), the call does nothing and returns success, so you can safely call the API without needing to worry about whether push is allowed."
Incidentally, if you want to disable HTTP/2 on Windows Server 2016, you can do so via the registry.
In addition to checking IIS logs, as David So suggested, you can verify HTTP/2 is being used by right-clicking on the headers row (Name, Status, Type, etc.) in Chrome's Network tab and checking off "Protocol"; you'll see "h2" for HTTP/2 responses. You can verify push promises are working by looking at the Chrome HTTP/2 internals page (chrome://net-internals/#http2) and looking at the "Pushed" and "Pushed and claimed" columns for your domain.
I am a beginner to ios development.
Can anyone tell me how to send data to server in xcode?
I have a requirement where I need to send device information to a server.
You need to first work out what kind of API the server you're talking to has exposed
Most modern web applications expose a Rest API (although I can only speculate as to what the server you mention is exposing). If Rest, then a good starting point should you not wish to write your own network layer is to use Restkit: https://github.com/RestKit/RestKit
If not Rest, then you need information on what the backend API is, and then go from there...
In it's most basic format you'll need to look at using NSURLRequest and NSURLConnection
NSURLRequest : Post data and read the posted page
http://codewithchris.com/tutorial-how-to-use-ios-nsurlconnection-by-example/
The answer proposed in Embed API credentials in iOS code is not an option for me.
My app communicates with a back-end SOAP API over HTTPS. My API credentials are sent in every request.
I don't have control over the server implementation, so I'm not able to add an intermediary authentication server and migrate to a token-based implementation.
Because I have to embed my credentials with my app's binary (I understand that this is far from ideal, on principle), i am looking for best practices to make my credentials as secure as is possible.
From what I've read, I've gathered:
Don't include credentials in an external file (such as a .plist)
Don't include credentials as simple NSString * const declarations. (Is using a char * safer?)
Don't do something obvious, like put my credentials in an Objective-C singleton called AuthenticationKeyManager
I also saw this article: http://applidium.com/en/news/securing_ios_apps_debuggers/
=> tldr: add release-mode code in the main.m to prevent the app from running if a debugger is attached
Note: I am able to implement SSL pinning.
Are there any other measures I can take to safeguard my access credentials?
There is described how create and use encrypted plist: http://aptogo.co.uk/2010/07/protecting-resources/
But aes key from it is stored in static NSString *sharedKey;
I'm new to network programming. This is probably a stupid question, would it be okay for my server to be in C++ for my iOS application?
iOS does not care what your server is programmed with. You can use whatever you feel comfortable with. Remember, you aren't going to be sending executable code to the server - you are just going to be sending requests and the server will send a response.
Yes, your server can be written in any way you want, provided you define the correct protocol (method of communication) between your iPhone app (client) and the server.
XML, JSON, HTTP POST or GET's, whatever. It should all work, provided you code both sides correctly.