Certificate Failure for UIWebView

If you're using UIWebView for connecting to a website which uses https, you rather hope that website has a trusted/validated certificate. Otherwise, it fails obscurely and you need to implement some tricks to get around this limitation. Btw, I am not sure how app store would react to this kind of change as it may cause some security risks.

Anyway, if you still want to go on, follow these steps. If you never heard of "Category" in Objective-C, I would rather suggest to look at the link (Objective-C categories), before implementing anything. Basically, a Category allows you to add additional methods to a class even the one you don't have the source code. For instance, if you want to add toCompare method to NSString class, you need to implement a category for it. Categories are so powerful; you can even use the instance variables (even if they're private) defined in the original source code. The only limitation is you cannot define new variables.

If we return to our original problem; we need to somehow turn off the certificate checking for the websites which has no valid certificate and insist on using https (this is most of the case your testing host). To do this, you need define a category for the NSURLRequest class and override the private allowsAnyHTTPSCertificateForHost method which takes NSString as a parameter and return bool. I would like to warn one more time to not use this method for the app that you're submitting for App Store, as this is a private method and I suspect that Apple will reject your app. But in any case, it is a good way to temporarily turn of certificate checking especially while testing your app towards the website which has not valid certificate yet.

Authentication/Authorization Protocols

Whoever gets his hand dirty for developing applications needs to handle some form of authorization/authentication in the first place. There are different protocols which gave developers ways to go for different needs and options. OpenId, OAuth and SAML are just some of them that I've had to face so far. Each exhibits different traits and differs in terms of purpose, functionality and the implementation. I'll lay down some of these traits for OAuth and OpenId below.

OAuth
OAuth is designed to solve authentication problem of an application who wants to use the data and functionalities of the provider. In this case provider can be Twitter or Facebook and they provide APIs to access user's data. In OAuth, provider returns an access token which provides the application the ability to access user's data on behalf of him. Since access token is used as primary measure of authorization, application don't need to see user's username and password. OAuth protocol is currently in version 2 which differs from the first one in terms of security and complexity. V2 supports security by SSL while the v1 expect application to provide this. So it is a huge win for v2. Twitter, Facebook and Google all supports v2 now.

OpenId

OpenId is another standart protocol which is used for authorization (as opposed to OAuth which is used for authentication mostly) in a decentralized manner. The basic logic behind OpenId is to eliminate the need for implementing sometimes complex and obscure authorization module for applications. Basically this is delegated to some third party namely OpenId providers. User can register himself through these providers and use the same username and password for authorization to another application. Google, Yahoo and IBM are just some of the providers...