[twitter-dev] Re: OAuth and native clients
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 -
[twitter-dev] Re: OAuth and native clients
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 -
[twitter-dev] Re: OAuth and native clients
Just wanted to second Sebastian's POV here. UserExperience is a key revenue driver for us, and OAuth for native mobile apps 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 on mobile clients. 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 other OAuth applications 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 other OAuth app. Is there any other way to do OAuth and at the same time, behave like a sensible application? Could Twitter implement a basic auth api call to perform the oauth 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 of OAuth, 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 -
[twitter-dev] Re: OAuth and native clients
Thanks for the pointer... I did some searches, but they were all focused on mobile clients. 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 other OAuth applications 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 other OAuth app. Is there any other way to do OAuth and at the same time, behave like a sensible application? Could Twitter implement a basic auth api call to perform the oauth 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 of OAuth, 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. --
