Okay, please tell me you know that I can create an app with a UIWebView that 
will take that password you type in faster than anything.

It is NOT secure.  This is my problem with oAuth.  The work-arounds cause a 
false sense of security.  oAuth was NEVER supposed to be used this way.  If the 
user does not trust the app, they should definitely not trust the developer 
that puts a UIWebView in it -- it is too easy to do a man-in-the-middle.  oAuth 
fits in well with webapps, not iPhone apps.

Anyway, this was all hashed out internally to Twitter -- that is why they came 
up with xAuth.



On May 30, 2010, at 3:50 AM, Rich wrote:

> You don't have to go from app to browser, embed a UIWebView and then
> in
> - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
> (NSURLRequest *)request navigationType:
> (UIWebViewNavigationType)navigationType {
> Look for your callback URL and read the query string and you'll be
> authorised, then just remove the UIWebView and use your application.
> The user never has to leave your app.
> Then the user gets MORE security that xAuth because they can see they
> are logging in on Twitter.com and not giving their password to an
> arbitrary application, which could still save their password without
> their knowledge.
> On May 30, 8:35 am, Jann Gobble <janngob...@gmail.com> wrote:
>> The requirement for users to go from app to browser to app is untenable for 
>> many of my users.  It is a major change to go from app to Safari and back to 
>> app.  Many users actually think that it the app is less secure (rightly or 
>> wrongly) because they have to exit it -- and go to the web -- in order to 
>> login.
>> Indeed, many of them do not understand the permissions that the oAuth system 
>> asks for when they get sent to the Twitter page.  Unfortunately with a phone 
>> like the iPhone you are dealing with many many users who are new to mobile 
>> devices in general and just wish to use twitter from within their favorite 
>> apps without the complications.  
>> Would you say that oAuth is good enough for Twitterific or Chirpie, Tweetie? 
>> Well, they are using xAuth.  All I wish to do is to provide my users with 
>> identical (and what they see is easy -- and safe) method of using Twitter.  
>> xAuth provides this.  oAuth does not.  Many users prefer a seamless 
>> experience to that of adopting a protocol that causes such a jarring user 
>> experience -- regardless of the perceived safety of oAuth over xAuth.  
>> Safety of one over the other comes down to how much you trust the app.  It 
>> no longer comes down to how much you trust Basic Auth.
>> I would have no problem if there was an even playing field where we could 
>> all have our app "signatures" in the Tweet -- and all have the same user 
>> experience where logins and permissions are concerned.  This is not the case.
>> Thanks for your input, though.
>> Jann
>> On May 30, 2010, at 12:03 AM, Rich wrote:
>>> You don't need xAuth to develop an iPhone app, oAuth workflow works
>>> just fine.
>>> Indeed I though xAuth was designed for clients without a decent mobile
>>> browser which isn't the case on the iPhone
>>> On May 29, 2:08 am, Jann <janngob...@gmail.com> wrote:
>>>> I sent an email in to api@ this week.  Got back a case # which, when
>>>> clicked, requires me to login.  It then tells me that the case 
>>>> #1008949does not exist.
>>>> So, I logged in under the twitter account that created the app and
>>>> created another ticket.  Got another ticket #1009859.  I am now
>>>> wondering how long this is supposed to take.  (if the first one is
>>>> invalid, then my new support case is now over 900 cases farther down
>>>> in the queue.  :(
>>>> Does anyone have any ideas?  I have seen (when searching on google)
>>>> that some people say it takes upwards of a week to get the approval.
>>>> I am stuck however because I cannot even test my iPhone app using this
>>>> method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to
>>>> implement and I can see no method to begin even testing using my own
>>>> account.
>>>> Shouldn't there be some way to (at least) test your app using the
>>>> username and password that was used to create the "Application" in
>>>> question?
>>>> Please give some insight.  Maybe I am missing something stupid.
>>>> Thanks!
>>>> Jann

Reply via email to