agreed,
regards,
Otávio Ribeiro

On Wed, Jul 8, 2009 at 11:52 PM, Zach <zcox...@gmail.com> 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 <sbal...@gmail.com> 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 <sdelm...@gmail.com> 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 <spec...@floodgap.com> 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*
> ckai...@floodgap.com
> > > > -- The cost of living has not adversely affected its popularity.
> --------------- Hide quoted text -
> >
> > > - Show quoted text -
> >
> >
>

Reply via email to