agreed, regards, Otávio Ribeiro On Wed, Jul 8, 2009 at 11:52 PM, Zach <[email protected]> wrote:
> > I'm going to 3rd Sebastian's POV. This is a serious problem that > needs to be addressed now. Mobile app developers want to integrate > their native apps with sites like Twitter and Facebook, but the > current user experience is so unacceptable that no one is going to use > it in its current form. > > For more on the topic: > > > http://www.hueniverse.com/hueniverse/2009/02/beyond-the-oauth-web-redirection-flow.html > > Kudos to the Twitter team for actually starting to think about a > reasonable solution to this problem. Facebook has the Connect for > iPhone library, but even that is just their terrible JavaScript-based > Connect login shown in an embedded browser. And forget about trying > to authenticate with Facebook from something like a BlackBerry app. > > We are anxiously awaiting a "OAuth for Mobile" option for the Twitter > API (as are a lot of other developers). Our app missed the "from > [MyApplication] using Basic Auth" cutoff so now every status update we > push says "from Twitter4J"... not the best for marketing purposes. We > would also love not having to store passwords on the device and send > them over the wire every time a user clicks the "Share" button. > > > > On Jun 30, 4:42 pm, morefromalan <[email protected]> wrote: > > Just wanted to second Sebastian's POV here. UserExperience is a key > > revenue driver for us, andOAuthfor nativemobileapps is really > > painful for the user. > > > > On Jun 19, 5:41 am, Sebastian <[email protected]> wrote: > > > > > Thanks for the pointer... I did some searches, but they were all > > > focused onmobileclients. > > > > > In my case, I'm not worried about the complexity of implementing > > >OAuth. I can deal with that, and once it's done, it's gone from the > > > picture. It's the user experience that worries me, as exposed on that > > > thread by the TTYtter example. > > > > > "Well, since people are asking, the workflow doesn't significantly > > > differ > > > from otherOAuthapplications and depends on the fact that access > > > tokens > > > don't expire. When people start TTYtter up for the first time without > > > an > > > access token (or TTYtter tries the access token and it fails), it asks > > > for > > > the usual request token, prints the access URL with the request token > > > it > > > wants the user to authorize, and waits for the user to authorize. > > > Twitter, > > > presumably, will say, "ok, tell your program to continue." Back on > > > TTYtter's > > > side, the user hits ENTER, and TTYtter exchanges its request token for > > > an > > > access token *and caches it* once it has verified it can successfully > > > hit > > > the user timeline for data. So far, this is not significantly > > > different than > > > any otherOAuthapp. " > > > > > Is there any other way to doOAuthand at the same time, behave like a > > > sensible application? > > > > > Could Twitter implement a basic auth api call to perform theoauth > > > authorization in the first place? Such a call would only be allowed > > > from clients that prove they need it, and could be revoked for rogue > > > clients. I know this lowers the security ofOAuth, but it only > > > officializes a hack many apps will try to implement. > > > > > On Jun 19, 12:39 am, Cameron Kaiser <[email protected]> wrote: > > > > > > > Or is the door for basic auth really closing forever? > > > > > > This has been discussed in a number of threads and an exact > determination > > > > has not yet been made. However, this might give you some context: > > > > > > > http://groups.google.com/group/twitter-development-talk/browse_thread... > > > > > > -- > > > > ------------------------------------ personal: > http://www.cameronkaiser.com/-- > > > > Cameron Kaiser * Floodgap Systems *www.floodgap.com* > [email protected] > > > > -- The cost of living has not adversely affected its popularity. > --------------- Hide quoted text - > > > > > - Show quoted text - > > > > >
