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 > > ----------------------
