Hi Jim,

any news on that?How close are you to address this?

Thanks.

On Sep 7, 9:54 am, "jim.renkel" <james.ren...@gmail.com> wrote:
> I've opened a feature request for this in the issues database:
>
> http://code.google.com/p/twitter-api/issues/detail?id=1011
>
> If you like this idea and / or think it's a good thing, please
> indicate your support both here and in the issues forum.
>
> If you don't like it and / or don't think it's so hot, I'd like to
> hear that too.
>
> Thank you in advance.
>
> Jim Renkel
>
> On Sep 5, 4:42 am, twittme_mobi <nlupa...@googlemail.com> wrote:
>
> > Jim,
>
> > Thanks for the broad summary,
> > I fully agree with you.
> > There should be some mechanism formobiledevices with
> > less resources forOAuth.
>
> > Regarding the source parameter of the Application, it is very
> > important with regards of e-marketing of the application itself.
>
> > Greetings!
>
> > On Sep 5, 2:08 am, "Jim Renkel" <james.ren...@gmail.com> wrote:
>
> > >OAuthis great, in certain circumstances. In others, it's not so great.
>
> > > Circumstances for which it is great include:
> > > -   consumer web sites; and
> > > -   consumer client applications that have access to a reasonable
> > > browser on
> > >     the client device
> > > in both cases with the qualification that the authorization pages of the
> > > service provider are in a language (e.g., English, Japanese, etc.) that
> > > is the same as that used by the consumer.
>
> > > In these circumstances,OAuthas defined by the specifications and
> > > implemented by twitter works very well.
>
> > > Circumstances for which it is not so great include:
> > > -   consumer client applications that do not have access to a reasonable
> > >     browser on the client device; and
> > > -   consumer client applications and web sites that are in languages for
> > >     which service authorization pages in those languages are not
> > > available.
>
> > > In these circumstances,OAuthas defined by the specifications and
> > > implemented by twitter does not work so well.
>
> > > Currently, in circumstances whereOAuthdoes not work very well, twitter
> > > client applications and web-sites can resort to Basic Authentication.
>
> > > The drawbacks to this are obvious:
> > > -   the user must give their twitter password to the client;
> > > -   at some point twitter will no longer support Basic Authentication;
> > > and
> > > -   the source of tweets created by these clients is "API" rather than
> > > the
> > >     client's name.
>
> > > Pooh pooh the last drawback if you will, but to some it is important.
>
> > > Now, the fact of the matter is that some users are perfectly comfortable
> > > in giving their twitter passwords to client applications and web-sites,
> > > even where those clients supportOAuth.
>
> > > I don't think these users should be penalized and forced to useOAuth
> > > if'n and when'n twitter drops support for Basic Authentication.
>
> > > And if'n and when'n twitter drops support for Basic Authentication,
> > > client applications and web-sites that now only support Basic
> > > Authentication will be forced to supportOAuth. Myself, I don't think
> > > that's an unreasonable requirement, but others may differ.
>
> > > And I don't think these creators should have to forgo having their
> > > client's name as the source of tweets their clients create, now or ever,
> > > just because their users chose to trust them to use Basic
> > > Authentication.
>
> > > So I propose the following enhancement to twitter'sOAuth
> > > implementation:
>
> > > Allow a userID and password to be included as optional parameters of an
> > >oauth/access_token request. If supplied and authentic, they would cause
> > > a valid access token to be returned without the user having visited the
> > > authorize URL and approved the access.
>
> > > Alternately, the userID and password could be optional on an
> > >oauth/request_token request, in which case, if supplied and authentic,
> > > the request would return a valid access token, rather than a request
> > > token, again without the user having visited the authorize URL and
> > > approved the access. The advantage to this alternative is it reduces by
> > > one the number of API calls needed.
>
> > > I believe either of these alternatives is a viable solution for the
> > > circumstances where the existingOAuthimplementation does not work so
> > > great.
>
> > > Comments expected and welcome.
>
> > > Jim Renkel
>
> > > -----Original Message-----
> > > From: twitter-development-talk@googlegroups.com
>
> > > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of
> > > twittme_mobi
> > > Sent: Friday, September 04, 2009 08:39
> > > To: Twitter Development Talk
> > > Subject: [twitter-dev] Re:MobileoAuth
>
> > > I am also interested inmobileoath solution.
> > > twitter guys should think of something before deprecating basic auth
>
> > > On Aug 20, 8:01 am, Cameron Kaiser <spec...@floodgap.com> wrote:
> > > > > I have amobilebased twitter client in the field and have
> > > implemented
> > > > >oAuthfor this client. Some of the devices are either very low
> > > memory
> > > > > or have primitive browsers that dont support the rendering of the
> > > > > 'allow' / 'deny' access page (http://twitter.com/oauth/authorize). I
> > > > > have tried the obvioushttp://m.twitter.com/oauth/authorizebutthis
> > > > > seems to serve the same standard webage.
>
> > > > > So Im looking for nat previous info or plans of a lightweight
> > > > > implementation ofoAuthaccess page for twitter.
>
> > > > I'm also particularly interested in such a page, especially one a text
> > > > browser could access such as Lynx or w3m.
>
> > > > --
> > > > ------------------------------------
> > > personal:http://www.cameronkaiser.com/--
> > > >   Cameron Kaiser * Floodgap Systems *www.floodgap.com*
> > > ckai...@floodgap.com
> > > > -- Adore, v.: To venerate expectantly. -- Ambrose Bierce
> > > ----------------------

Reply via email to