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: email@example.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 > > > ----------------------