Thank you for your prompt reply Isaiah,

No worries.  Glad to help out.


Thank you also for the offer of emailing you directly, but I think
your code is also precious for other newbie like me who want to know
more about this OAuth thing :)

It wasn't so easy to figure out a nice way to do this stuff. I figured it would be a good thing to share. Glad it's helped.

About changing application type to be "Browser", then there is
"Callback URL:" box that I have to fill, which I have no idea what do
I have to fill in there.
But I tried it anyway, and same result.

The callback URL can be any URL you like. After a successful authorization this is the URL that's loaded. You should specify the URL both in the twitter app setup and also as a constant in the YHTwitter.m file on line 25:
#define kYHOAuthTwitterCallbackSuccessURL       @"http://twitter.com/";

Through the browser delegate methods the client will know that the callback URL was reached and the authorization was granted by the user. This triggers the example app to close the browser window and save the OAuth info to the keychain.

Although I would imagine you would want to change it to your own web site for practical reasons, leaving it as http://twitter.com/ should *work* at least for testing purposes.
Isaiah

YourHead Software
supp...@yourhead.com
http://www.yourhead.com



On Jul 24, 2009, at 1:06 PM, Fares Farhan wrote:


Thank you for your prompt reply Isaiah,

Thank you also for the offer of emailing you directly, but I think
your code is also precious for other newbie like me who want to know
more about this OAuth thing :)
About changing application type to be "Browser", then there is
"Callback URL:" box that I have to fill, which I have no idea what do
I have to fill in there.
But I tried it anyway, and same result.

Fares

On Jul 24, 10:58 pm, Isaiah <supp...@yourhead.com> wrote:
My example was built right as the pin code method was invented/
implemented in the API.  So my example still uses the "Browser" method
that doesn't require a pin code.

If you go to your application settings page in twitter and set your
Application Type to be "Browser" you should be good to go.

As I understand it the PIN code was invented to help "clients" that
couldn't detect if the browser had been sent to the success callback
URL.  However, my example doesn't have this issue.
My example embeds the browser and communicates directly with it to
determine when the callback URL is sent.  This technique obviates the
need for the pin code.

I like to think of my example as a "hybrid app" -- neither purely a
desktop client nor really a web app -- but a little bit of both in the
right places.  ;-)

I've considered adding the pin code, but it seemed to further
complicate an already challenging UI without adding any value.

If you have any other issues with the example code, please feel free
to email me directly.  I'd be happy to help out.

Isaiah

YourHead Software
supp...@yourhead.comhttp://www.yourhead.com

On Jul 24, 2009, at 12:04 AM, Fares Farhan wrote:



Dear Twitter developers,

First, I apologize if I misplace the question.

I've cloned Isaiah's git repository of his AOuth implementation from
http://github.com/yourhead/OAuth_ObjC_Test_App/tree/master

but I experienced an issue that after the web sheet closed, there is
no place that I can put the PIN retrieved from the authentication
result, or anywhere in the code that I need to pass the oauth_verifier
parameter along with other params.

the debugger said that ther is "Operation could not be completed.
(NSURLErrorDomain error -1012.)"

Thank you in advance for any response,

Cheers,

Fares

Reply via email to