Magic!
Now it works.. thanks a ton Isaiah :)
On Jul 25, 4:40 am, Isaiah wrote:
> > 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 ashttp://twitter.com/should
> *work* at least for testing purposes.
> Isaiah
>
> YourHead Software
> supp...@yourhead.comhttp://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 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
