Some people have expressed difficultly in using MPOAuth on the iPhone, so I commited a test iPhone app that merely shows how to link in MPOAuth and make use of it on the iPhone. I wrote this a while ago while testing, but have updated it now to demonstrate how to implement an MPOAuthAPIDelegate, use an inline UIWebView for user authorization, implement a custom URI handler to return control to your application and then finally make an authenticated request.
MPOAuthAPIDelegate
MPOAuthAPIDelegate allows an application to be a part of the OAuth authentication dance by providing a callback URL as well as choosing whether the user should automatically be taken to the authentication URL via the system’s default web browser.
Callback URIs
While custom callbacks URIs are a useful way for client side applications to return control to their application, many OAuth producers do not allow consumers to make use of them even for client applications. If you’re unable to get this to work it may be due to the fact that your OAuth producer does not allow it and doesn’t inform you of such. There’s also what I feel is a hacky solution for capturing url load requests and then returning the control to your application manually. This is a hack for the above problem so that you may use arbitrary domains like example.com to redirect.
Setup
In order to use MPOAuthMobile, you need to first configure it to connect to an OAuth endpoint and set your consumer key and secret in RootViewController.m lines 13 and 14.
13
14
| #define kConsumerKey @"key"
#define kConsumerSecret @"secret" |
Among the supported OAuth endpoints in MPOAuth is twitter, so you can set http://twitter.com as the baseURL used to create your instance of MPOAuthAPI on line 39-40 and it’ll automatically do everything you need.
39
40
| _oauthAPI = [[MPOAuthAPI alloc] initWithCredentials:credentials
andBaseURL:[NSURL URLWithString:@"http://twitter.com/"]]; |
Usage
Once you’ve compiled the application in Xcode, it will install into the simulator or device and when it launches the OAuth dance will automatically commence by getting the unauthorized request token, and opening an inline webview for user authorization. Once you’ve provided the user credentials, the web view is animated off the display stack and the state updated again. At this stage you’re free to type in whatever method you’d like to perform on the remote endpoint. In this case I used /statuses/friends_timeline.xml to see my timeline.
Download
The code can be found in the mpaouthconnection project on google code under the MPOAuthMobile subdirectory
Steve Troughton-Smith, author of such fine iPhone apps as Speed and the jailbreak Dock enhancer Stack, has secured permission to release the game that originally made jailbreaking worthwhile, Lights Off. With new original graphics also by Adam Betts, and a rewritten code base featuring CoreAnimation snazzyness, soon we’ll all be again consumed with turning off the lights on our iPhone. While the app has not yet been submitted to the App Store you can avail yourself of news and updates about the app by visiting the website directly at lightsoffapp.com
If you’ve wanted to do anything with WebServices recently you’ve likely encountered OAuth, the open specification for client server data transmission. In a nutshell OAuth allows a desktop or web application a secure method by which to obtain user credentials for an online service without ever having to actually get the user’s username or password directly. It protects users credentials since they don’t need to give them out to multiple parties, and improves site security by giving users the tools with which to turn off the access of applications and services to their data.
Due to the proliferation of these services a common need exists to quickly be able to connect to to them without having to write yet more complicated code to do this when you just want to build your snazzy new application. Since I happen to enjoy using and writing APIs I took it upon myself to write one for OAuth for Mac and iPhone Cocoa applications. To this end, I’ve created the MPOAuthConnection set of classes that make it trivial to talk to these applications.
At the high level you merely need to tell MPOAuthAPI about the URL to your intended web service and give it your consumer key and secret and it will take care of the rest of the work of authenticating, retrieving access keys, and storing them on the user keychain on Mac OS X and iPhone*. There is a sparse delegate API for you to take part in the authentication sequence if necessary. Once authenticated you can perform method requests asynchronously or synchronously on the remote API using -performMethod:withTarget:action: or -dataForMethod: respectively.
The API is built in a layered way that allows you to, if so interested, jump in at lower levels for more direct control of the server communication and interact more directly with the classes doing the work, but so far I don’t believe this will very often be necessary. I’m using this code in a current project so it works well for me, and I’ve fixed the bugs I’ve encountered so far. I’m hoping you guys can find others, but of course if you don’t run into any that’s great too.
This code was built using the OAuth Core spec as a reference, along with the Yahoo! OAuth guide and the Google OAuth guide. It’s been tested by myself connecting to a few of the Yahoo! and Google OAuth services. It includes code excerpts from Jonathan Wight and Steve Reid for base64 encoding and HMAC-SHA1 hashing.
MPOAuthConnection on Google Code
Edit: Properly refer to OAuth as OAuth
The entire notion that for a product like the iPhone, in-store activation would not be an issue is absurd. Everyone knew it would be a complete clusterfuck, and sure enough, it turned out to be a complete clusterfuck. One of the many screw ups that Apple didn’t discover until they were fscking up people’s plans and leaving them with no working phones is that they can’t do anything with an account that has a corporate discount or FAN number attached. If you’re one of the unlucky few to get your phone bricked you can still follow steps 2-4 of Method A to fix it. If you have a corporate discount on your current calling plan then you can not activate it on that plan or for your current number in the store regardless of how long you waited in line. There are only two methods to correct this problem and make the time you spent in line worthwhile.
Method A:
1. First you buy the phone anyway on a new plan with a new number at the Apple Store.
2. Then with your new phone you use the maps app to look up the nearest AT&T store and make your way there
3. At the AT&T store tell them to cancel your new plan, put your old SIM card in your new phone and upgrade the phone on your current plan to the iPhone 3G.
4. You now have a working phone with your current number with your corporate discount still attached.
Method B:
Buy it at the AT&T store where they can do this all correctly in the first place. Now if only they had more than 5 iPhones in each shipment…
Beta 3 is out, it has voice. Wanna fight about it?