Re: [twitter-dev] Re: Will requesting DM access now disable xAuth for my app?

[Ed Finkler]

Thanks for being my guinea pig! 8D

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com


On Sunday, May 29, 2011 at 12:49 PM, twittelator wrote:

 I poured a 4-shot breve latte just in case, flipped the switch at
 https://dev.twitter.com/apps, and was delighted when:
 
 - shipping Twittelators already deployed can use and continue to get
 valid RW XAUTH Tokens
 - those XAUTH tokens still work
 - New RWDM tokens are correctly given to new in-house builds of
 Twittelator
 
 So, I can totally relate to the feeling of Am I about to hose 1
 million users? but, especially with the enhancements due this week
 from Twitter, I think we can all make a smooth transition to the new
 flow.
 
 On May 27, 11:31 pm, Ed Finkler funkat...@gmail.com (http://gmail.com) 
 wrote:
  Fellers,
  
  For testing as we prep our apps for the switch to PIN-based auth, I'd like
  to change the default access level to Read, Write,  Private Message.
  However, I'm concerned this will disable xAuth for existing users
  immediately, rather than once we hit June 30.
  
  Can I do this, or should I register a new application? Or do I have other
  options?
  
  Thanks,
  
  -Ed
 
 -- 
 Twitter developer documentation and resources: https://dev.twitter.com/doc
 API updates via Twitter: https://twitter.com/twitterapi
 Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
 Change your membership to this group: 
 https://groups.google.com/forum/#!forum/twitter-development-talk


-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

[twitter-dev] Will requesting DM access now disable xAuth for my app?

[Ed Finkler]

Fellers,

For testing as we prep our apps for the switch to PIN-based auth, I'd like 
to change the default access level to Read, Write,  Private Message. 
However, I'm concerned this will disable xAuth for existing users 
immediately, rather than once we hit June 30.

Can I do this, or should I register a new application? Or do I have other 
options?

Thanks,

-Ed

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

[twitter-dev] Re: A new permission level

[Ed Finkler]

Matt,

Ultimately I understand the issues with xAuth and granularity. Frankly, if 
you just ditched xAuth entirely, I can see decent arguments for it.

However, we've made a significant investment in the xAuth UX. If we have to 
change it, 13 days is simply not sufficient for most devs. It will be a 
stretch for Spaz, given that we are all volunteer and do it in our spare 
time. Folks who have to deal with app store submissions and the like are 
even more under the thumb.

2 months, I think is much more reasonable. In addition, real effort being 
put forth by the dev relations team to show how to migrate to a solid oAuth 
flow on desktop and mobile would be very useful to many devs.

Good luck.

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

[twitter-dev] Saved search destroy method not always effective?

[Ed Finkler]

I'm having some problems getting the saved search destroy method to
actually destroy a search. I'm seeing this both in curl and from Ajax
calls. The following paste shows me making a call to list my searches
from curl, deleting one of the searches, and then getting the list
again. The search does not appear to have been deleted.

http://friendpaste.com/33zXI3iZCKN23vc1NlhCeJ

Anyone else seeing this?

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com

[twitter-dev] Re: Deprecation of following and notification elements

[Ed Finkler]

Has this been implemented? I'm getting results that seem to indicate
so.  Example:

 curl 
 http://twitter.com/friendships/exists.json?user_a=spaztestuser_b=funkatron;
true
 curl 
 http://twitter.com/friendships/exists.json?user_a=funkatronuser_b=spaztest;
true

so those users are following each other. However, user info returned
in an authenticated request shows following:0 (that's the integer
zero)

 curl -k -u funkatron:## https://twitter.com/users/spaztest.json | 
 prettyjson
[...]
following:0,
[...]

 curl -k -u spaztest:perlsucks https://twitter.com/users/funkatron.json | 
 prettyjson
[...]
following:0,
[...]

I believe that following is supposed to indicate of the
authenticating user is following the requested user, but even if it's
the other way around, it seems wrong. Am I missing something, though?

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com



On May 11, 5:18 pm, Doug Williams d...@twitter.com wrote:
 Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The
 defects report that methods returning user objects (see users/show for an
 example [3]) are returning incorrect or invalid values for the following
 element.

 The fix for this inconsistency is in fact non trivial [4]. The problem lies
 within the interaction of the application logic, caching layer and database
 design. The persistent data behind following and notification values are
 separate from the user data in our architecture, so to keep these elements
 valid in cache alongside user objects adds a large amount of complexity.

 Developers made it obvious that these data are a priority and we want to
 ensure they available. We also want to guarantee they are accurate and that
 performance remains good. Given the problems explained above, we are going
 to be making a number of changes to the API so that you can rely on the
 following or notification data.

 Deprecations:
 The following elements are to be removed from all returned user objects
 returned by the API:

 1) following
 2) notifications

  This deprecation will not occur until we finish the following:

  Additions:
 To continue to provide access to this data we will be creating a new method:

  Issue 532 [4] outlines the need to perform a mutual following lookup. We
 will use a method similar to that described in this issue to deliver
 following, followedby, notification and pending (in the case of
 protected users) data with a single call.

 We realize this change will cause an increase in API usage for some
 applications. Therefore we are going to increase the default API rate limit
 across the board. This should help absorb some of the costs for applications
 attempting to do interesting things with social graph data. The number will
 be somewhere between 101 and 200 calls but we still need to look at growth
 projections and current hardware capacity before settling on a definite
 number.

 We plan to begin work on this relatively soon with the fix coming in a few
 weeks. We do not have a planned ship date at this time but will communicate
 specifics with developers as they are determined. We anticipate the new
 number of calls and a documented schema for the new method will be made
 available before the new method ships. Please watch this thread and
 @twitterapi for the incremental details.

 1.http://code.google.com/p/twitter-api/issues/detail?id=419
 2.http://code.google.com/p/twitter-api/issues/detail?id=474
 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show
 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm
 5.http://code.google.com/p/twitter-api/issues/detail?id=532

 Thanks,
 Doug
 --

 Doug Williams
 Twitter Platform Supporthttp://twitter.com/dougw

[twitter-dev] Re: Deprecation of following and notification elements

[Ed Finkler]

Or, as I think slightly more clearly, perhaps this is an example of
the inconsistency discussed in the OP. Sorry for the noise if that's
the case.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On May 27, 11:50 am, Ed Finkler funkat...@gmail.com wrote:
 Has this been implemented? I'm getting results that seem to indicate
 so.  Example:

  curl 
  http://twitter.com/friendships/exists.json?user_a=spaztestuser_b=fun...;
 true
  curl 
  http://twitter.com/friendships/exists.json?user_a=funkatronuser_b=sp...;

 true

 so those users are following each other. However, user info returned
 in an authenticated request shows following:0 (that's the integer
 zero)

  curl -k -u funkatron:##https://twitter.com/users/spaztest.json| 
  prettyjson

 [...]
 following:0,
 [...]

  curl -k -u spaztest:perlsuckshttps://twitter.com/users/funkatron.json| 
  prettyjson

 [...]
 following:0,
 [...]

 I believe that following is supposed to indicate of the
 authenticating user is following the requested user, but even if it's
 the other way around, it seems wrong. Am I missing something, though?

 --
 Ed Finklerhttp://funkatron.com
 Twitter:@funkatron
 AIM: funka7ron
 ICQ: 3922133
 XMPP:funkat...@gmail.com

 On May 11, 5:18 pm, Doug Williams d...@twitter.com wrote:

  Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The
  defects report that methods returning user objects (see users/show for an
  example [3]) are returning incorrect or invalid values for the following
  element.

  The fix for this inconsistency is in fact non trivial [4]. The problem lies
  within the interaction of the application logic, caching layer and database
  design. The persistent data behind following and notification values are
  separate from the user data in our architecture, so to keep these elements
  valid in cache alongside user objects adds a large amount of complexity.

  Developers made it obvious that these data are a priority and we want to
  ensure they available. We also want to guarantee they are accurate and that
  performance remains good. Given the problems explained above, we are going
  to be making a number of changes to the API so that you can rely on the
  following or notification data.

  Deprecations:
  The following elements are to be removed from all returned user objects
  returned by the API:

  1) following
  2) notifications

   This deprecation will not occur until we finish the following:

   Additions:
  To continue to provide access to this data we will be creating a new method:

   Issue 532 [4] outlines the need to perform a mutual following lookup. We
  will use a method similar to that described in this issue to deliver
  following, followedby, notification and pending (in the case of
  protected users) data with a single call.

  We realize this change will cause an increase in API usage for some
  applications. Therefore we are going to increase the default API rate limit
  across the board. This should help absorb some of the costs for applications
  attempting to do interesting things with social graph data. The number will
  be somewhere between 101 and 200 calls but we still need to look at growth
  projections and current hardware capacity before settling on a definite
  number.

  We plan to begin work on this relatively soon with the fix coming in a few
  weeks. We do not have a planned ship date at this time but will communicate
  specifics with developers as they are determined. We anticipate the new
  number of calls and a documented schema for the new method will be made
  available before the new method ships. Please watch this thread and
  @twitterapi for the incremental details.

  1.http://code.google.com/p/twitter-api/issues/detail?id=419
  2.http://code.google.com/p/twitter-api/issues/detail?id=474
  3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show
  4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm
  5.http://code.google.com/p/twitter-api/issues/detail?id=532

  Thanks,
  Doug
  --

  Doug Williams
  Twitter Platform Supporthttp://twitter.com/dougw

[twitter-dev] Re: Can Twitter please pick a From: and stick with it?

[Ed Finkler]

You do a ton of great things, Matt. We all make mistakes, but you and
the rest of the crew there do a bang-up job.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On May 7, 11:24 am, Matt Sanford m...@twitter.com wrote:
 Hi all,

      I left last night while they were rolling this back to the old  
 long format addresses. Re-reading the logs this morning it seems like  
 there was some sort of problem and it was rolled back. Waiting for the  
 engineer in question so I can find out more details but based on what  
 I'm seeing it looks like an unrelated problem. I expect the long-style  
 addresses to be re-deployed with our first deploy today.

      As far as poor communication: that's fair. I made this change  
 after talking with the mail processing folks (ok, the guy) and product  
 folks and I broke your filters. I'm sorry about that and when you  
 brought it up I fixed the issue, wrote the tests, replied to the mails  
 and begged the deploy engineer to make it an emergency. I tried to  
 communicate things.

      I should have told the list (and probably posted to  
 blog.twitter.com) this user-facing email change was coming … surprise  
 is overrated. I definitely should have thought more about how it would  
 effect filtering. Totally my bad … you can send flaming sacks of dog  
 poop to REDACTED.

 Thanks;
   – Matt Can do no right Sanford

 On May 7, 2009, at 8:15 AM, Chad Etzel wrote:



  Hi Matt,

  When you decide on the final format and deploy, will you let us know,
  please?  I'm leaving my email filters in limbo until then.

  Thanks,
  -Chad

  On Thu, May 7, 2009 at 12:59 AM, TjL luo...@gmail.com wrote:

  *sigh*

  Seriously? I've already started telling people to change their  
  filters
  and now they're going to break *again*.

  This is why daddy drinks.

  All kidding aside, I don't understand how a change like this gets
  pushed out without the left hand knowing WTF the right hand is  
  doing —
  which is what it looks like (from an outsider's perspective)  
  happened.

  IMO/FWIW: You've gotten too big to make these sorts of changes  
  without
  more consideration and communication. It makes me look bad as a
  developer, and it makes Twitter look bad.

  The irony is that you're a company built around communication.

  TjL

  On Wed, May 6, 2009 at 6:55 PM, Matt Sanford m...@twitter.com  
  wrote:

  Hi all,

    The change in from address was meant to fix the 'allow images'  
  but in the
  process broke some ISP spam filters, some spam reporting, and a  
  great many
  people's mail filters. We're working on rolling that back now.  
  Sorry for the
  disruption.

  Thanks;
  – Matt Sanford / @mzsanford
     Twitter Dev

  On May 6, 2009, at 3:13 PM, TjL wrote:

  FWIW I think nore...@twitter.com is the right choice, it's  
  certainly
  a lot easier for image display, etc.

  But it sounds like John Adams thinks this is going to change  
  back. I
  hope this will be clarified.

  On Wed, May 6, 2009 at 5:58 PM, Matt Sanford m...@twitter.com  
  wrote:

  Hi there,

   We had changed the from address to try and improve bounce  
  reporting and
  prevent being marked as spam by major ISPs. When we added the HTML
  formatting we found that we needed a consistent address for the  
  'always
  display images' option in many clients so we changed things  
  around again.
  Hopefully this will be the last change as it causes us a bunch  
  of work as
  well. I'll keep an eye out for future changes and try and let  
  people
  know.

  Thanks;
  – Matt Sanford / @mzsanford
    Twitter Dev

  On May 6, 2009, at 2:53 PM, TjL wrote:

  The email notifications for new followers used to come from  
  (From:)

  Twitter nore...@twitter.com

  then it changed to

  Twitter twitter-follow-emailname=domain@postmaster.twitter.com

  then it changed to

  Twitter nore...@twitter.com

  again.

  Every time you do this, every single person using TwitReport  
  has to
  change their filters, and I spend 2 weeks, at least, explaining  
  to
  people why it stopped working, and some number of people probably
  assume that things are broken on my end and stop using it  
  altogether.

  I'm not making a dime off of this project (nor do I want to),  
  it's
  something that I'm doing to make Twitter a bit nicer to use, but
  having something as basic as this change twice and break the  
  entire
  thing is a bit of a pain in the ass and a not-insignificant  
  waste of
  time.

  So I hope that y'all will keep this one, since you've liked it  
  enough
  to use it twice now :-)

  THAT SAID, I'm glad that the *format* of the notifications has
  improved. I certainly think that is the right way to go.

  - TjL

[twitter-dev] Re: Twitter's official comment on our disabling of OAuth

[Ed Finkler]

That is, in fact, what Beta typically means: not suitable for
production use.  Overuse of the term by a few popular web apps
notwithstanding.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Apr 23, 9:25 am, mikehar m...@picnik.com wrote:
 Also, I'm a little taken aback by the it's beta rationalization for
 the massive disruption in service. It's one thing to mark it as public
 beta, it's another thing entirely to define 'beta' belatedly as not
 suitable for production use. Does that mean we get an SLA on the non-
 beta APIs?

 On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote:

  Hi guys, is there an ETA for it to be restored ? It seems Oauth's
  recommended approach is to simply add a warning notice on
  authorization until this is fixed (this is what Google did). Anyways,
  even with this security flow, oauth is safer than providing twitter
  credentials to third parties...

  Thanks!
  Pierre

  On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote:

   Bill,
   The majority of our developers find OAuth sufficient because they are
   writing a Web applications. We are pleased that the deprecation of the
   source parameter lowered our support load and continues to drive adoption 
   of
   our preferred authentication scheme.

   There are of course other cases where developers find the current
   implementation's beta status or browser requirement concerning. I have yet
   to reject a source parameter request that provides a valid argument
   explaining why OAuth does not meet the application's needs.

   Thanks,
   Doug Williams
   Twitter API Supporthttp://twitter.com/dougw

   On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson
   billrobertso...@gmail.comwrote:

I respectfully disagree.  (I would colorfully disagree, but you seem
pretty beat up right now and you don't deserve any guff)  I think
developers of smaller apps see that little tag-line as a good source
of advertising, and it seems inaccessible now if you're new (right?
wrong?).  You can only get it if you use OAuth, but OAuth is now
disabled?

Anyway, just my $0.02.  Prioritize it like everything else you need to
do (i.e. it's the 37th #1 thing on your list.)

Good luck.

On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote:
 We don't consider source registration a key feature. It's an
 incentive we provide to our developers. We wanted to encourage new
 developers to look into OAuth. It won't be in beta forever, after all.

 We have to balance the reality of testing a new technology in our
 stack with encouraging that technology's adoption. OAuth will provide
 the Twitter developer community with a number of benefits, and that's
 the direction in which we want to move, even while there are kinks to
 work out.

 On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote:

  If beta for you guys means still in testing, not suitable for
  production use, then why depreciate key features from basic auth 
  like
  source registration before you have a production ready release?

  On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote:
 http://blog.twitter.com/2009/04/whats-deal-with-oauth.html

  In short: there's a security issue with OAuth, and the major OAuth
  providers are working together to patch the vulnerability before
  information about the issue is publicly released. That information
  will be available athttp://oauth.net/atmidnight, PST.

  In cooperation with this consortium of other OAuth providers
  (including Yahoo!, Google, Netflix, etc.), we agreed not to 
  disclose
  the nature of the vulnerability, nor even that a vulnerability
  existed, until all members of the group agreed to do so. I 
  apologize
  for what must have seemed unnecessarily tight-lipped communication
  around this issue, but please understand that we and the other
  companies involved are trying to mitigate the impact of this
  vulnerability as much as possible.

  Please also note that our OAuth support is in beta, albeit public
  beta. We have not suggested to developers that they rely solely on
  OAuth until our support of the standard leaves beta. I know that 
  some
  companies practice a policy of perpetual beta, but at Twitter, 
  we do
  not. For us, beta really means still in testing, not suitable 
  for
  production use.

  Thanks for your patience and understanding.

  --
  Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

 --
 Alex Payne - API Lead, Twitter, 
 Inc.http://twitter.com/al3x-Hidequoted text -

   - Show quoted text -

[twitter-dev] Re: first try

[Ed Finkler]

Okay, first off, the Fatal error is happening because PHP on your
install is set-up to time-out scripts after 60 seconds (this is to
avoid runaway processes on the server).

I'm not sure exactly why your socket connection is timing out. One
possibility is that a local firewall is blocking outgoing connections
until you explicitly allow them.

I'd recommend installing a Windows binary of curl for testing on the
command line, and also grabbing a copy of the Charles debugging proxy
to see what's actually being sent and received (if anything!).

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 29, 10:37 pm, Bill william...@gmail.com wrote:
 Hi, I tried to access the twitter API with the following code but I
 get the error:
 Contacting Twitter...
 n
 Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp
 \htdocs\twitter.php on line 26

 I am running this from an apache server on my home computer 
 at:http://127.0.0.1/twitter.php

 I have not applied for any special account with twitter, just my
 regular twitter id and password were entered. Can anyone tell me why
 this is not working?
 Thanks!

 ?php
 $twitter_username = '';
 $twitter_password = '';

 $errno = 0;
 $errstr = '';
 $response = '';

 function httpRequest($host, $path = '/', $method = 'GET') {

   global $errno, $errstr, $response;
   global $twitter_username, $twitter_password;

   $header  = $method $path HTTP/1.1rn;
   $header .= Host: $hostrn;
   $header .= Accept-Encoding: nonern;
   $header .= Authorization: Basic  . base64_encode
 ({$twitter_username}:{$twitter_password}) . rn;
   $header .= Connection: Closernrn;

   $sock = fsockopen($host, 80, $errno, $errstr, 30);
   if (!$sock) {
       die(pstrongfsockopen() error:/strongbr /$errstr ($errno)
 /p);
   } else {
       fwrite($sock, $header);
       while (!feof($sock)) {
       $response .= fgets($sock, 128);
       }
       fclose($sock);

       $response = trim(str_replace(array('', ''), array('lt;',
 'gt;'), $response));
       return true;
   }

 }

 echo pContacting Twitter.../pn;

 //!-- Replace the following code for later examples from the article
 --
 httpRequest('twitter.com');
 echo pResponse:br /hr /pre$response/prehr //pn;

 ?

[twitter-dev] Re: The OAuth Conundrum

[Ed Finkler]

It is a case of tool maturity, but it's a heck of a steep hill to
climb up when comparing HTTP Basic Auth to any alternatives.
Comparable toolsets for a wide range of languages and environments
won't be available for a long time, if ever.

In addition, my real concern, as stated above, is with apps and
scripts that do automated tasks. These kinds of things frequently
execute outside of a modern GUI desktop environment, and all the OAuth
workflows I've seen (including your example) have assumed that a
graphical web browser is a click away. That's simply not the case
with, say, the scripts that pull data down for my data mining
experiments.

I am afraid that going OAuth-only will effectively kill off these
kinds of apps. That would suck, in my opinion.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 26, 1:44 pm, Gavin Bell m...@gavinbell.com wrote:
 Fair point, there do seem to be more twitter apps than say Flickr apps,
 but is this not just a case of tool maturity though?

 It is hard to beat cron and curl, but tools 
 likehttp://intridea.com/2009/3/23/twitter-auth-for-near-instant-twitter-apps
 will make it easier to get past the auth setup and on to making an  
 interesting app.

 OAuth is still pretty young compared to basic auth, the tools will get  
 better I think
 I still think that OAuth as a single framework for web and desktop is  
 a desirable model to aim for.

 Migrating the current Basic Auth acquired users to OAuth tokens will  
 be a challenge though.

 registering your OAuthness with twitter.com or responding to a  
 particular API call could then start a token issuing process?

 On 26 Mar 2009, at 17:19, Ed Finkler wrote:



  Exactly how I feel Cameron. Use of HTTP Basic Auth has contributed
  greatly to interesting, unexpected uses of the API, especially those
  that involve automation. I absolutely feel that the availability of
  OAuth is a Good Thing, and for many use cases it is practically
  essential, but it is also unsuitable for some.

  OAuth as the only authentication scheme will create a much higher
  barrier for simple exploration of the API. That will be disappointing
  to me if it happens.

  --
  Ed Finkler
 http://funkatron.com
  Twitter:@funkatron
  AIM: funka7ron
  ICQ: 3922133
  XMPP:funkat...@gmail.com

  On Mar 26, 1:10 pm, Cameron Kaiser spec...@floodgap.com wrote:
  My friend sent me this blog post [1] (I believe the author is on  
  this
  list) and though I agree with it generally there is one sentence  
  that
  really stood out to me it's a fantastic solution to _authenticate
  other
  web apps_.  After mulling this over I think that this sentence  
  should
  have been the author's final conclusion.
  Ideally Twitter would have implemented token based authentication  
  from
  the start as Flickr did, which would have avoided this whole  
  migration
  of authentication techniques.

  However Twitter have said that OAuth is their preferred  
  authentication
  approach for the future, to roughly quote Doug from Tuesday night's
  Twitter Devnest meeting. Given that I feel it is much more confusing
  to have one means of authenticating desktop applications and another
  for web applications.

  I think it's hard to say ideally. Ideally *from a security  
  perspective*,
  sure, but it has been observed and said by many people, not merely  
  yours
  truly, that Twitter's API would probably not have the wide  
  utilization it
  does if they had insisted on a token based auth from the very  
  beginning.

  How many scripts are out there that are basically curl and a cron  
  job? A lot.
  Unless they can migrate turning off Basic Auth will shut them down,  
  which
  may or may not be a bad thing, but it was so easy to implement that  
  they
  became Twitter users. That does count for something.

  This again should not be construed as a vote of no confidence in  
  OAuth
  because I'm converting TTYtter (a desktop app) to it too, and there  
  are clear
  advantages for certain functional domains. But I think it needs to be
  pointed out that OAuth is not always *the* solution, nor always the  
  best
  solution in a field of inferior ones.

  --
   
  personal:http://www.cameronkaiser.com/--
    Cameron Kaiser * Floodgap Systems *www.floodgap.com* 
  ckai...@floodgap.com
  -- I am Pentium of Borg. Division is futile. You will be  
  approximated. --

[twitter-dev] Re: 4-legged OAuth discussion

[Ed Finkler]

The workflow you describe has actually always bothered me, and I think
is the kind of thing OAuth is trying to combat.

Twitpic is not an official service of Twitter, but it seems to be
treated as such by many clients, which silently share their users'
Twitter authentication information. Any client that shares
authentication info with a 3rd-party service without clearly
indicating that it's doing so (and offering the option to cancel the
action) is, in my opinion, violating the user's trust. I would
strongly encourage developers to stop this practice immediately.

I think it would be cool to have a one-round OAuth grant to more than
one consumer, but *please* make sure that all consumers are broken out
and granted access individually.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 25, 8:21 pm, Ivan ivan.kiri...@gmail.com wrote:
 I started a discussion on the OAuth mailing list about 4-legged OAuth
 in the context of Twitter OAuth consumer 
 applications.http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a...

 I'd love to have the input from the Twitter developer community.

 The problem is essentially that OAuth access tokens aren't
 transferable. For example, a Twitter user on TweetDeck can input a
 username  password, which lets TweetDeck post a picture to TwitPic.
 If TweetDeck were granted OAuth access to the user's Twitter account,
 TwitPic couldn't verify the access tokens easily, and couldn't
 communicate to Twitter with them.

 Applications moving to OAuth could mean fewer mashups, which is bad.

 OAuth providers should have a way of authenticating to Consumer A that
 Consumer B has access to a user's account.

 The access to the Twitter API could still require independent OAuth
 access grants for each consumer.

 What do you think?

 Ivanhttp://tipjoy.com

[twitter-dev] Re: The OAuth Conundrum

[Ed Finkler]

Exactly how I feel Cameron. Use of HTTP Basic Auth has contributed
greatly to interesting, unexpected uses of the API, especially those
that involve automation. I absolutely feel that the availability of
OAuth is a Good Thing, and for many use cases it is practically
essential, but it is also unsuitable for some.

OAuth as the only authentication scheme will create a much higher
barrier for simple exploration of the API. That will be disappointing
to me if it happens.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 26, 1:10 pm, Cameron Kaiser spec...@floodgap.com wrote:
   My friend sent me this blog post [1] (I believe the author is on this
   list) and though I agree with it generally there is one sentence that
   really stood out to me it's a fantastic solution to _authenticate  
   other
   web apps_.  After mulling this over I think that this sentence should
   have been the author's final conclusion.
  Ideally Twitter would have implemented token based authentication from  
  the start as Flickr did, which would have avoided this whole migration  
  of authentication techniques.

  However Twitter have said that OAuth is their preferred authentication  
  approach for the future, to roughly quote Doug from Tuesday night's  
  Twitter Devnest meeting. Given that I feel it is much more confusing  
  to have one means of authenticating desktop applications and another  
  for web applications.

 I think it's hard to say ideally. Ideally *from a security perspective*,
 sure, but it has been observed and said by many people, not merely yours
 truly, that Twitter's API would probably not have the wide utilization it
 does if they had insisted on a token based auth from the very beginning.

 How many scripts are out there that are basically curl and a cron job? A lot.
 Unless they can migrate turning off Basic Auth will shut them down, which
 may or may not be a bad thing, but it was so easy to implement that they
 became Twitter users. That does count for something.

 This again should not be construed as a vote of no confidence in OAuth
 because I'm converting TTYtter (a desktop app) to it too, and there are clear
 advantages for certain functional domains. But I think it needs to be
 pointed out that OAuth is not always *the* solution, nor always the best
 solution in a field of inferior ones.

 --
  personal:http://www.cameronkaiser.com/--
   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
 -- I am Pentium of Borg. Division is futile. You will be approximated. 
 --

[twitter-dev] Re: Proof of identity rather than authorization

[Ed Finkler]

On Mar 22, 6:17 am, GraemeF grae...@gmail.com wrote:
 Hi Elliott,

 This scenario worked well with basic authentication; you could just
 delegate the login to Twitter. Now I don't see a way to do it without
 requiring the user to create another account so that the token can be
 associated with it.

Well, Basic Auth still works *now*. I've personally advocated it not
go away ever. If you agree, you may want to make this preference
known.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com

[twitter-dev] Re: How many accounts is too many?

[Ed Finkler]

Twitter is opt-in. If you don't want certain kinds of content in your
friends timeline, you just don't follow a particular account. I don't
think we should get terribly dogmatic about how an account is used
(beyond things that violate TOS). In fact, the flexibility of Twitter
and its API is a big reason why it has such a large dev community, I'd
say.

I subscribe to a couple broadcast-only news ticker accounts, because
I like the content and prefer to have it in my friends timeline over
other delivery systems.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 10, 1:15 pm, TjL luo...@gmail.com wrote:
 On Tue, Mar 10, 2009 at 11:37 AM, Clinton clin...@iannounce.co.uk wrote:

  You're confusing Twitter with RSS.

  RSS is a way to push this type of information out to people.

  Twitter is the wrong tool.

  Well, is it? Yes, you're right, I AM thinking of using this like RSS,
  but is that necessarily wrong?

 If you ask just about anyone who uses Twitter a lot, they would tell
 you yes, it is wrong.

 Google twitter is not rss (including the quotes) and read some of the 
 results.

 RSS is RSS. People who want RSS go to RSS.

 What's the advantage of Twitter? That people can get them via SMS? Not
 at the rates you're talking about publishing.

 With the exception of Breaking News I don't see any sort of purpose
 to duplicate what RSS provides via Twitter.

  To put it in context, there are lots of people who read the day's
  obituaries (or other family announcements) in their daily newspaper. I
  could imagine these people being interested in receiving a list of new
  notices daily.

 Sounds like a perfect job for a daily email digest. I'd sign up for
 one of those if my local paper provided it.

 I would not, however, sign up for their Twitter feed.

 Seriously, I'm not trying to be a PITA or smart-aleck.

 There's not enough info in 140 characters to tell me what I need to
 know, so all you can do is post a name, age, and a link to your
 website.

 You are probably not going to send any Breaking News! Maybelle Lewis,
 90, died updates. Once a day is plenty.

 I'd MUCH rather give you my email address and get the daily digest
 where I can get the full obit (and you can stick some other marketing
 information in the email if you'd like :-)

  My previous number of 3,500 was the number of new notices across a
  whole site (which consists of many newspapers), but for individual
  newspapers, we're talking about anything between 0 and 100 per day-
  usually more like 20-30.  That is manageable.

 FWIW I believe that 20-30 a day is going to rate you as a nuclear follow 
 cost

 http://www.followcost.com

 which I point to as further evidence that this is not how Twitter
 users intend to use Twitter.

  If you/they are determined to do this, then the best way to do it
  (least-worst) solution is to make it so that you are sending the
  fewest number of status updates as possible which are as specific as
  possible.

  Sure. In this context, that amounts to a tweet for each new notice
  that is published - any less and we'd just be sending stats: 20 new
  obituaries, which is meaningless to everybody.

 Yes, but

 Obituaries for John Smith, Kelly Green, Joseph Smith, Al Jones, [and
 so on]http://tr.im/;

 would be better than 10 separate posts

  I'd welcome other ideas for how to incorporate twitter into the site,
  or pointers to useful implementations by other companies.

 How other companies are using Twitter might be a good thing to checkout.

 Look athttp://twitter.com/zapposfor example.

 They aren't link-blasting you with sale information or special promo
 codes. It's an actual person typing in actual messages, making
 connections with actual people.

 On the other side, there ishttp://twitter.com/cnnwho has 34,561
 followers, but even they posting less than 20 times a day. And they're
 CNN.

 Look at how Rachel Maddow is using ithttp://twitter.com/maddow
 Pointers to her show but not JUST that.

 If there is an on-scene reporter who wants to take on an official
 Twitter account, that'd be one thing, but if it's going to be
 automated, I think it's missing the point.

 TjL

[twitter-dev] Re: How to get started?

[Ed Finkler]

There's also a book coming out from O'Reilly which may be of use to
you:

http://oreilly.com/catalog/9780596157791/index.html

That's the rough cuts version, which pretty much what it sounds
like. You can pre-order the whole dealie on Amazon tho.

Disclaimer: I and a couple other people on here did the tech editing
work on this.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 1, 12:51 pm, Elker elia...@gmail.com wrote:
 (I'm deeply sorry if I'm not supposed to post here or whatsoever.)

 Hi!
 I've got experience in HTML, CSS and kind of some experience with PHP
 and MySQL.

 As a fulltime Twitter-user, I would also like to learn how to use the
 Twitter API. I have from previous times no experience with APIs. I
 barely know what it is.

 So, my question is, where do I start? My head is a mess right now
 after reading about words such as social graph, curl and that weirdo
 stuff. xD

 Appreciating help, thanks in advance.

[twitter-dev] Re: MAKE TWITTER WORK WITH GOOGLE TALK AGAIN ALREADY!

[Ed Finkler]

This isn't an API issue. You should address it to http://help.twitter.com/.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Mar 2, 2:03 pm, APintheLP aphillip...@gmail.com wrote:
 come on guys...this is getting rediculousdo your jobs and don't
 neglect services just cause you're busy.

 AP

[twitter-dev] Re: 500 internal error

[Ed Finkler]

Try using a debugging proxy like Charles so you can see the exact
request being sent. That aids greatly in sorting out things like this.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Feb 25, 5:48 am, Paul Haenel paul.hae...@googlemail.com wrote:
 Hi,

 Im getting a internal error which i execute this JavaScript function:

 function setTwitterStatus(twitterStatus){
     var twitterStatus = 'status='+twitterStatus;

     alert(twitterStatus);

     var req = new XMLHttpRequest();

     req.open('POST', 'http://twitter.com/statuses/update.json',1);
     req.setRequestHeader('Authorization', 'Basic '+Base64.encode
 (twitterUsername+':'+twitterPassword));
     req.onreadystatechange = function(){
         if(req.readyState ==4){
             alert(req.responseText);
         }
     }
     req.send(twitterStatus);

 }

 twitter status is is a plain text like hello or  is working hard.

 here is s acopy of the response:

 Status: 500 Internal Server Error
 Content-Type: text/html

 htmlbodyh1500 Internal Server Error/h1/body/htmlStatus:
 500 Internal Server Error
 Content-Type: text/html

 htmlbodyh1500 Internal Server Error/h1/body/html

 Any help appreciated.

 Thanks Paul

Re: a simple workaround for lack of OAuth

[Ed Finkler]

On Sun, Jan 4, 2009 at 7:32 PM, Jesse Stay jesses...@gmail.com wrote:
 On Sun, Jan 4, 2009 at 5:20 PM, Lachlan Hardy lach...@lachstock.com.au
 wrote:

 Those who expect OAuth to be a panacea for identity theft on Twitter
 simply don't understand the issues involved. Operating a modern
 computer involves a lot of trust - trusting applications you run on
 your machine, trusting web sites you set up accounts on, and the like.
 And when you trust, there's always the potential for getting burned.
 OAuth doesn't change that fundamentally.

 I agree completely with your post, Ed. I put forward my thoughts on OAuth
 and phishing in April last year:
 http://log.lachstock.com.au/past/2008/4/1/phishing-fools/

 Basically, I think OAuth is awesome, but the idea that it's going to
 somehow stop phishing is extreme.

 I don't get how it won't help fight phishing. Right now the worm is being
 spread via an App.

Help us out here with what worm you mean -- there are lots of them 8)

 (if it's not, then Twitter really needs a Captcha on the
 Twitter login page)  At the moment all Twitter can do is chase down IPs to
 kill the App.

Sure.

 With OAuth it would be as simple as killing the API key
 itself and the worm would be dead.

If the malicious application uses OAuth via Twitter, yes.

 Could they go in and create another one?
  Probably, but it makes it a whole lot harder for someone to create such a
 worm.  This is the reason most of the Facebook worms right now are spreading
 through simple screen scraping and not the App platform.  It's too much work
 to do it on the App platform there because Facebook would just shut you down
 each time their alarms went off.

I'd note that it used to be too much work to spam Google Groups
because of CAPTCHAs too, but almost all CAPTCHAs can be defeated now
programatically and via mechanical turk-style attacks. I and a few
others have to review posts from all new users for this reason.

Also, why do you assume that phishing attacks would have to come via
Twitter messages, though? Most come via email or web content on other
sites. Twitter currently uses email notifications for several events
-- faking those would be quite easy to do, for example.

OAuth may have mitigated (not blocked) *one* particular worm that was
sending messages directing people to a phishing site. And yes,
removing everyone's shoes does stop the shoe bombing attack. Whether
or not this actually makes you *safer* is something we should very
carefully consider. Personally, I'd say it helps, but only a little --
far less than most of our Thought Leaders claim.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: a simple workaround for lack of OAuth

[Ed Finkler]

On Sun, Jan 4, 2009 at 8:55 PM, Jesse Stay jesses...@gmail.com wrote:

 So what do *you* recommend Ed (that goes for everyone that is criticizing
 OAuth, including Alex)? I see a lot of criticism against OAuth, but I see no
 suggestions for a solution.

Perhaps you're mistaking criticism with an attempt to make for
realistic expectations, and temper an artificial urgency.

Generally I think OAuth is a Good Idea, and I think it's probably a
good step for Twitter to take. I think I can say Alex agrees, or he
and the rest of the API team wouldn't be implementing it.

It's not really my job to tell Twitter what to do – first off, I think
they have people with very good security backgrounds in place, and
secondly I'm not on their payroll. But if you actually want to hear a
few things, I'll toss them out. I don't have time or motiviation atm
for a lot of detail (we just lost a family friend tonight to cancer),
but I'm happy to talk about them another day in detail if you want.

- immediately cease the development of any web-based applications that
require user credentials. I generally don't think that you're keeping
your user's best interests in mind when you do this.
- educate users about risk acceptance: what it means to trust a web
application with your credentials (or OAuth permissions), and what the
consequences could be if trust is broken.
- educate users about how to identify phishing attacks
- possibly implement some personal site ID techniques on the Twitter
homepage, like user-chosen identifier images

Even if you do a great job on all of these, though, you will always
have some people who fall for it.

 Right now, I think it's a step in the right
 direction - I see a lot of theories here, but not a lot of urgency to fix
 the problem.  As I said, I don't care what the solution is - I just need
 something, other than requiring my users to enter their plain text usernames
 and passwords.  There's huge urgency here - what's the solution to the
 problem?

There is no solution.

Really. There isn't. People who work in security will tell you this.
The security industry spends millions and millions of dollars on
application trust issues, and there is no solution. There are things
you can do, but you can't solve the problem. You can only *mitigate*
risk.

People clamoring for OAuth -- this is the urgency you refer to -- are
participating in security theater. They want it implemented not
because it will make things a little better, but because they have
been whipped up into a frenzy by ye olde Thought Leaders and want
*something* to be done. I was completely serious about my shoe bomb
analogy, because it's a classic security theater – oh shit, you could
put a bomb in your shoe! better check everyone's shoes! It's a
temporary PR fix, but it doesn't solve the problem other than making
people feel better -- until the next security flavor of the week comes
around.

If you seriously want to study this kind of thing further, I think
starting off with Schneier's Beyond Fear: Thinking Sensibly About
Security in an Uncertain World would be a good idea. As a developer,
you should also dig into all the security info you can, and make
security a first-level concern. If you're a PHP dev (I know a lot of
folks here are), I'd probably start out with Chris Shiflett's
Essential PHP Security. Rails devs should keep an eye on
http://www.rorsecurity.info/.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: a simple workaround for lack of OAuth

[Ed Finkler]

I think Scoble likes to hear himself talk, and loves to stir up drama.
It's how he keeps people paying attention to him.

I'd find more reputable sources for that argument.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Fri, Jan 2, 2009 at 12:44 AM, Richie rocketeer.so...@gmail.com wrote:

 I think it's getting more urgent day by day:

 http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/

 Richie
 http://twitter.com/RMetzler


 On 8 Dez. 2008, 18:09, Alex Payne a...@twitter.com wrote:
 It won't be available for testing this week, but should be available
 before the end of the month.  I'd definitely encourage you not to
 launch on it, though, as it will be a beta.



 On Mon, Dec 8, 2008 at 08:16,Richierocketeer.so...@gmail.com wrote:

  Hi Alex,

  do you have any updates on whenOAuthis available?

  Currently I'm doing the finishing touches on a new service and would
  love to let the users chooseOAuthfor authentication instead of
  requiere them to give me their secret pw. I'm experienced in using
 OAuthso I expect to get it working in a couple of hours.

  Do you think Twitter will enableOAuththis week or should I start my
  service with user/pw-authentication first?

  Richard

  On Nov 27, 12:38 am, Alex Payne a...@twitter.com wrote:
  As I don't know the entire schedule of our UX team, I can't.  I would
  say less than a month and closer to a week by far, but please don't
  hold me to that.

  On Wed, Nov 26, 2008 at 15:41, Amir Michail amich...@gmail.com wrote:

   On Nov 24, 5:05 pm, Alex Payne a...@twitter.com wrote:
   We're currently waiting on our User Experience team to put the final
   touches on a BETA release of ourOAuthsupport.  It's going to have
   bugs, to be sure, but we should have it out there soon.

   Could you give us a time estimate?  In a week?  A month?

   Amir

   On Mon, Nov 24, 2008 at 12:53, Stut stut...@gmail.com wrote:

On 24 Nov 2008, at 15:13, fastest963 wrote:

A better alternative would be to just create an API key for
every user. Instead of entering username/password, they would enter
their secret API key?

This is far less secure thanOAuthand is actually not much better than
requiring a username and password.

One of the core benefits ofOAuthis the ability to be very specific
regarding what each authorised application is allowed to do, on a per
application basis. It also allows you to selectively revoke the 
permissions
of any specific application without needing to ask or even tell the
application about it. To do this with the API key system you 
effectively
need to re-authorise every app you use when you want to block just 
one of
them. No real difference between this and having to change your 
password.

I would much prefer that the guys (and gals) at Twitter concentrate 
on
gettingOAuthproperly implemented (which is harder than it sounds) 
than
their attention gets diverted by developers too impatient to wait 
for the
right solution to the problem.

-Stut

--
   http://stut.net/

   --
   Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

  --
  Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

 --
 Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

Re: a simple workaround for lack of OAuth

[Ed Finkler]

On Fri, Jan 2, 2009 at 1:36 PM, Mark Ng ng.mar...@gmail.com wrote:

 Whilst there's an element of truth in your statement (just about all
 of the prominent tech bloggers remain prominent by stirring up drama),
 lots of people have been saying similar things for a long time.  Ad
 hominem attacks don't change the fact that the message is right. You
 could start here : http://adactio.com/journal/1357 .

Agreed, and that's a much better source.


 I think we all understand, however, that the twitter engineering team
 first needed to make twitter stable before they could add features
 like this one.  Now that they've largely done that, it appears they're
 responding to demand for features like this one, which is great news.

Yep. So not really a lot of point in continuing the oh boy, this is a
big problem! thing, I think, when they're on it and have given many
updates here recently. That's not a criticism of you in particular,
but of folks who apparently don't search the archives before posting
something along the lines of Scoble said this is a big deal, so you'd
better do it! It doesn't help in any way.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: a simple workaround for lack of OAuth

[Ed Finkler]

On Fri, Jan 2, 2009 at 1:41 PM, Cameron Kaiser spec...@floodgap.com wrote:
 So let's say Scoble is right. How, in fact, does OAuth prevent a bad
 actor from using credentials to act badly?

 OAuth solves many problems; it doesn't solve this one.

And this.

Re: Sometimes tweets are not made

[Ed Finkler]

If you're testing your app locally, use Charles to examine the data:

http://www.charlesproxy.com/

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Tue, Dec 23, 2008 at 9:02 PM, Stecki ma...@stecki.de wrote:

  I still haven't seen a Charles trace on what the client is actually 
  sending.
  If the client is indeed sending a bogus Expect: header, then all this line 
  is
  doing is suppressing it.

 I for my part had never explicitly set an Expect: header. Seems that
 Curl is doing this automagically. But until tonight it never was a
 problem - so the new apache may indeed be a bit more picky, what to
 accept.

 My code was:

 curl_setopt($ch, CURLOPT_HTTPAUTH,CURLAUTH_BASIC);
 curl_setopt($ch, CURLOPT_USERPWD,user:pass);
 curl_setopt($ch, CURLOPT_URL, $url.?status=.urlencode($t));
 curl_setopt($ch, CURLOPT_POST,true);
 curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
 curl_setopt($ch, CURLOPT_HEADER, false);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

 and I just added

 curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

 to get it to work.

 Sorry, I don't know how to get the verbose trace info.

Re: rate_limit_status

[Ed Finkler]

The web site does not affect API limits. Your account may have another
issue if it's been blocked for this long.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Thu, Dec 18, 2008 at 11:01 AM, Mike shotzomb...@gmail.com wrote:



 On Dec 18, 10:53 am, rhysmeister therhysmeis...@hotmail.com wrote:
 HI,

 I've recently noticed that calls to the rate_limit_status seem to
 extend my reset time by exactly one hour after I have hit the 100
 request limit. For example if I hit my 100 limit at 4:00 PM then the
 reset time is 5:00PM. If I check this at 4:45PM it then states the
 reset time is 5:45PM. It seems to happen for a couple of times before
 stopping. Is this known behavior?

 Thanks,

 Rhys

 I've had similar troubles.  I haven't been able to log in via API for
 a few days, but was unaware that there may be a connection to checking
 my rate_limit_status.  I was under the impression that using a web
 browser did not affect my reset time.

 http://twitter.com/mike_white

 The no API thing is really bumming me out.

Re: rate_limit_status

[Ed Finkler]

Oh, I see now. So it changes each time you *check*, not just each time
you hit 100. Yes, that doesn't sound right.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Thu, Dec 18, 2008 at 12:32 PM, rhysmeister
therhysmeis...@hotmail.com wrote:

 Definitely something funny going on.

 Around 16:30 this afternoon rate_limit_status was reporting that my
 reset time was 17:15. When querying this at 17:26 the reset time was
 reported as 2008-12-18T18:26:04+00:00.

 On Dec 18, 4:07 pm, Ed Finkler funkat...@gmail.com wrote:
 I believe the reset time indicates when your block will be lifted, so
 having it be 1 hour after you hit the limit seems sensible.

 --
 Ed Finklerhttp://funkatron.com
 AIM: funka7ron
 ICQ: 3922133
 Skype: funka7ron

 On Thu, Dec 18, 2008 at 10:53 AM, rhysmeister

 therhysmeis...@hotmail.com wrote:

  HI,

  I've recently noticed that calls to the rate_limit_status seem to
  extend my reset time by exactly one hour after I have hit the 100
  request limit. For example if I hit my 100 limit at 4:00 PM then the
  reset time is 5:00PM. If I check this at 4:45PM it then states the
  reset time is 5:45PM. It seems to happen for a couple of times before
  stopping. Is this known behavior?

  Thanks,

  Rhys

Re: Following limits - again.

[Ed Finkler]

This is definitely something you'd have to work with Twitter Support
on -- this list is just for discussion of application development.
Sorry to hear of your troubles tho.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Wed, Dec 17, 2008 at 9:06 AM, Lianne lianne.tur...@gmail.com wrote:

 Hi there,
 I hope someone can help me out with this.  I run the officialPETA
 account for People for the Ethical Treatment of Animals, and we
 reached a following limit of 2,000 a few months ago.  I sent a request
 to Twitter Support asking to have the limit removed, and they wrote
 back saying we wouldn't have limits anymore because we're a large
 organization.  After following some weird number over 2,000 (something
 like 2,137), it gave me the same error message again.  When I
 unfollowed people, I still couldn't follow more as long as it was over
 2,000.  We'd like to be able to follow back our followers, and to
 reach out to people who are PETA supporters and don't know about our
 twitter account.  I'm just not sure why the following limit was
 imposed again, after we had been told it wouldn't be a problem, and
 would like it to be removed again, if possible.  Thanks so much!

 Also, the message I receive when I try to follow more than 2,000
 people is all in broken html code, instead of the message I got at
 first at the top of the list.  Thanks!

Re: direct_messages new NOT working

[Ed Finkler]

Try grabbing the HTTP request and response with a debugging proxy like
Charles. That will let us know what's really being sent and received.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Thu, Dec 11, 2008 at 1:14 AM, sMan [EMAIL PROTECTED] wrote:

 Oops, sorry for the lack of detail. Here is the body of the
 postTwitter method (as i said, I'm able to post to other twitter URLs
 within the API with this same piece of code):

 def postTwitter(url, hashParams)
  url = URI.parse(url)

  req = Net::HTTP::Post.new(url.path)
  req.basic_auth($username, $password)
  req.set_form_data(hashParams, ';')

  res = Net::HTTP.new($twitter, $twitPort).start {|http| http.request
 (req) }
  puts res

  case res
  when Net::HTTPSuccess, Net::HTTPRedirection
return 'true'
  else
return 'false'
  end
 end

 On Dec 10, 5:00 pm, Alex Payne [EMAIL PROTECTED] wrote:
 If you provide the full request/response output from your call to the
 method, I'm sure somewhat can tell you what's going on.  Thanks!



 On Wed, Dec 10, 2008 at 16:36, sMan [EMAIL PROTECTED] wrote:

  Hi guys, I just started kicking the tires on the API (thanks, btw!)
  and am having a horrendous time posting to /direct_messages/new.xml.
  The response that comes back is invalid request which doesn't give
  me much to debug or go off of. I am able to post to the udpate/status
  urls just fine so I dont think its my code. here is how I'm doing the
  post in Ruby:

  postTwitter(http://twitter.com/direct_messages/new.xml;, {text =
  'this is a test', user = 'saumil})

  postTwitter is my wrapper method to execute the http request and works
  for other urls, just not this one.

  Thanks!
  --S

 --
 Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

Re: Follow / Unfollow Error?

[Ed Finkler]

Try using a debugging proxy like Charles. It should capture data
coming from your app, whether it's in the browser or an AIR app.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Wed, Dec 10, 2008 at 3:27 PM, Ninjamonk [EMAIL PROTECTED] wrote:

 thanks Alex, its not a rate limit issue as I am not hitting it that
 much (about 3 times max a minute).

 Unfortunately there is not way to get the body of the response in as3
 when it throws an error.

 Error #2032: Stream Error. URL: 
 https://twitter.com/friendships/create/shytalk.xml
 is an example of the error that as3 throws.

 As you can see its correct, the user is authenticated and the verb is
 POST.

 I have tried this with 2 users and get the same problem. The users
 were me (ninjamonk) and a test account I setup called justatestuser
 (which is the account I tried to friend shytalk)

 Cheers

 Darren

 On Dec 10, 7:33 pm, Alex Payne [EMAIL PROTECTED] wrote:
 400 usually means that you've run into our rate limit.  You can find
 out for sure by looking at the body of the response we've sent to you,
 which contains an informative error message.

 If you need the rate limit lifted for your development period, please
 apply for whitelisting athttp://twitter.com/help/request_whitelisting.



 On Wed, Dec 10, 2008 at 11:30, Ninjamonk [EMAIL PROTECTED] wrote:

  I am using the as3 twitter script and so can't get the response just
  the 400 bad request. I am thinking its most likely my code if no one
  else is getting this.

  I wonder if its to do with the flash player I have on my mac.

  if its working for others then I wouldn't worry about it.

  Cheers
  Darren

  On Dec 10, 5:21 pm, Alex Payne [EMAIL PROTECTED] wrote:
  I'd need an example of the error you're running into to be sure it's
  the same as the one Steve reported.  Given the specifics of the
  account he's having trouble with, I'm guessing it's not the same
  issue.

  On Wed, Dec 10, 2008 at 05:49, Ninjamonk [EMAIL PROTECTED] wrote:

   I am using the as3 twitter script and am getting the same problems I
   think. I cannot get follow to work even though everything is the way
   it should be.

   do we have an update on this Alex?

   On Dec 6, 7:33 am, Alex Payne [EMAIL PROTECTED] wrote:
   This is new to me; yours is the only report I've seen.  Can you please
   provide full request/response output, either on this list or privately
   to me?

   On Fri, Dec 5, 2008 at 15:28, Steve Ng Ming Yeow [EMAIL PROTECTED] 
   wrote:

There seems to be a majorfollowerror happening. Following someone
generates an error that someone is already on list, and unfollowing
someone generates an outright error. Even when following is
successful, no email is generated.

This is an massive error for our service. Any idea when/how it will 
be
fixed? 9 hours  and counting i believe

   --
   Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

  --
  Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

 --
 Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x

Re: Using CAPTCHAs to get more followers on twitter.

[Ed Finkler]

 And so I think there's a real need for a service that helps you
 increase followers, especially ones who might actually find your
 tweets interesting.

Need seems like a strong word.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: favorited value is null in JSON

[Ed Finkler]

Indeed, I basically can't use TwitterFon until this gets sorted out.
(I'm aware of the workaround script online, but don't want to de-fav
items in my timeline).

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Sun, Dec 7, 2008 at 10:50 PM, Kazuho Okui [EMAIL PROTECTED] wrote:

 I have received the null value of favorited statuses more frequently today.

 Thousands of my app users have been struggling for these days. (I
 guess several other iPhone clients also crash when they receive the
 null values.)

 I submitted the new version of my app to AppStore 4 days ago but I
 guess it will take for another few days to get an approval. If you
 could address the things on the server side, it would help my users
 very much.

 Regards,
 Kazuho

 On Thu, Dec 4, 2008 at 10:32 PM, Alex Payne [EMAIL PROTECTED] wrote:

 Thanks much!

 On Thu, Dec 4, 2008 at 22:12, Kazuho Okui [EMAIL PROTECTED] wrote:
 I attached another example which is a result of curl. it contains a
 request/response headers and a JSON content.

 I hope this will help to find the issue.

 Thanks,
 Kazuho

 On Thu, Dec 4, 2008 at 1:21 PM, Kazuho Okui [EMAIL PROTECTED] wrote:
 Hello Alex,

 I attached JSON objects which my app users gave me. Thus, I don't have
 any request header, but the request is
 http://twitter.com/statuses/friends_timeline.json; with auth header.

 The JSON objects contains favorited:null instead of favorited:true
 or false randomly.

 Thanks,
 Kazuho


 -- Forwarded message --
 From: Alex Payne [EMAIL PROTECTED]
 Date: Thu, Dec 4, 2008 at 12:11 PM
 Subject: Re: favorited value is null in JSON
 To: twitter-development-talk@googlegroups.com



 If you could please provide example request/response output that would
 help us track this down.  Apologies for the inconsistency.

 On Wed, Dec 3, 2008 at 17:28, Kazuho Okui [EMAIL PROTECTED] wrote:

 Today, I suddenly received a JSON value which favorited value is null
 instead of bool.

 http://code.google.com/p/twitter-api/issues/detail?id=179

 This crushes my Twitter client because it assumed that the value is
 boolean. The application is written in Objective-C, so the value type
 is very important for my client.

 The favorited value was null or true until October, then true or false
 until today. Could you please define exactly the type of favorite
 value?? Also, could you use boolean to all favorited status?

 Thanks,
 Kazuho




 --
 Alex Payne - API Lead, Twitter, Inc.
 http://twitter.com/al3x





 --
 Alex Payne - API Lead, Twitter, Inc.
 http://twitter.com/al3x

Re: Helpful PHP Optimizations

[Ed Finkler]

Good suggestions. The fastest connection to mysql (if you're using
mysql, of course) will likely be via the mysqli extension API, and
with the mysqlnd driver. PDO is quite lightweight, though, so it
probably isn't a big slowdown point for you. It will use the mysqlnd
driver if you have it installed.

http://php.net/manual/en/book.mysqli.php
http://forge.mysql.com/wiki/PHP_MYSQLND

If you're doing the same inserts with different data multiple times
per script execution, you definitely want to use prepared statements.
If the driver supports it natively, you should get a speed increase
because the db engine won't have to do an analyze/compile/optimize
step on every insert.

http://php.net/manual/en/pdo.prepared-statements.php

Also, if you have a set of inserts that will happen during a single
script execution, you might look at disabling auto-commit and using
transactions + a final commit at the end. This should speed up the
time spent inserting data considerably.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Sat, Nov 15, 2008 at 11:47 AM, fastest963 [EMAIL PROTECTED] wrote:

 PHP Optimizations

 PDO (http://www.php.net/pdo) is a must! Speeds up database
 transactions

 1) Store as much data as possible into database
 2) Store data as arrays for each updating and fetching (see serialize)
 3) Always use an index field in mysql
 4) Limit echos/prints

 Most Important: If connecting to pages (ex. API calls) use CURL Multi
 Connects
 (http://www.ibuildings.com/blog/archives/811-Multithreading-in-PHP-
 with-CURL.html) (use 2nd example)

 Also try to make use of Forking (http://immike.net/blog/2007/04/08/
 fork-php-and-speed-up-your-scripts/)

 MYSQL Optimizations

 1) Use BIGINT 255 unsigned fields for ids or anything that could get
 really large
 2) Remember OPTIMIZE


 Finally, if you are storing a lot of data. Do the following:
 Take the ID (index), hopefully not a number, and md5 it.
 Then store into a specific table based on the first letter of the md5.
 Example:

 $user = fastest963; //store user
 $let = md5($user); //md5 username
 SELECT * FROM.$let[0].users WHERE `username` = '$user' ; //$let[0]
 is the first letter of the md5

 Tables would be created like this:
 First make 0users table. Then copy and make 1-F tables.
 0users, 1users, 2users, 3users, 4users, 5users, 6users, 7users,
 8users, 9users, ausers, busers, cusers, dusers, eusers, fusers
 Those would be all the table names, thus splitting your data per table
 by 16.


 I hope that helps people out when optimizing their scripts. These have
 allowed me to process 2000+ tweets per sec via PHP. Any questions?
 Feel free to comment!

 Thanks,
 James Hartig

Re: No OAuth Support just made Techmeme

[Ed Finkler]

I think we know this already, and allowing a flavor of the day story
to influence things unduly would be overreaction.

I trust Alex, Matt and co. to make the proper decisions in regards to
what takes precedence.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Thu, Nov 13, 2008 at 4:52 PM, Jesse Stay [EMAIL PROTECTED] wrote:

 I'm sure you're aware of this, but the lack of OAuth or secure login support
 just got really public as it made Techmeme.  IMO, for my App at least, this
 would be first priority if I were to ask for anything.  Anyone else agree?
  Here's the Meme:

 http://www.techmeme.com/081113/p38#a081113p38

 Jesse

Re: Search UI and API suggestions

[Ed Finkler]

On Thu, Nov 6, 2008 at 1:34 PM, Craig Hockenberry
[EMAIL PROTECTED] wrote:

 As a user, there are a couple of things I'd like to see in search
 (both the Advanced UI form and in the API):

 1) The ability to search for replies to a given tweet ID. The use case
 for this is when someone asks a question like What's the best place
 to get T-shirts printed in small runs?. The only way to search for
 answers is by using the original poster's screen_name, which contains
 a lot of noise in the results. Specifying the original tweet's ID
 would be much more accurate (now that clients like Twitterrific are
 starting to set it when replies are posted.)

+1



 2) I'd like to do a search for @chockenberry that are not replies to
 me. Periodically, I do searches to see what people are saying about
 me. I'm not in interested in @chockenberry This a reply, I'm
 interested in Just saw @chockenberry and man is he tall. A vanity
 mode :-)

I guess you could kinda get these now, but you'd have to do
client-side filtering to dump the stuff you don't want.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: Create Twitter Account using the API?

[Ed Finkler]

This has been discussed before. The concern is that it would allow for
mass creation of accounts, ripe for abuse by spammers. I can't speak
for Twitter, but I suspect that it will be a while before we see
something like this, if at all.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Tue, Nov 4, 2008 at 9:45 AM, Dawson [EMAIL PROTECTED] wrote:

 Is it possible to create a twitter account using the API, if not, can
 anyone suggest an alternative programmatic method that would allow
 this - Thank you.

Re: Create Twitter Account using the API?

[Ed Finkler]

On Tue, Nov 4, 2008 at 10:13 AM, Dawson [EMAIL PROTECTED] wrote:

 It's not for spam purposes that we would wish to impliment such a
 feature. We're working on a portal that allows users to update
 multiple digital destinations with news on their brands and other
 topics of interest. Instead of asking users to go to each of these
 destinations, register, then come back to our portal to update them,
 we were looking to create the accounts for them where applicable.

 I can see how this might be used for spam, if twitter didn't impliment
 email URL authentication, which it does ... rendering that argument
 pretty much mute.

I could see that as useful, yeah. Did you file a feature request in
the issue tracker yet?

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Re: Twitter status source!!

[Ed Finkler]

Read the wiki, plz:

http://apiwiki.twitter.com/FrontPage

On Tue, Nov 4, 2008 at 6:20 PM, charlesmex [EMAIL PROTECTED] wrote:

 Hi.

 I am deploying a twitter application. I use the API for update status
 and put the ApplicationName in source post param, but ever show
 from web. How display my application name in source?

 Thanks for all.

 P.D. Sorry for bad english :/

Re: is the rate limit what it says it is?

[Ed Finkler]

100 req/hr per IP for non-authenticated requests.
100 req/hr per account for authenticated requests.
POST requests (like updating status) are not limited.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Tue, Oct 14, 2008 at 6:26 PM, X10 [EMAIL PROTECTED] wrote:

 When my app requests the rate limit from the server, I get 100.
 However, my app does about 20 timeline requests per hour, and I do a
 few status updates, less than ten per hour. With some resends and a
 verify credentials, I don't count more than 50 requests each hour.
 However, the app does get 400 errors. I do preemptive authentication,
 so I don't get 401 errors that count for my rate limit.
 So my question is, does a rate limit of 100 mean that I can do a total
 of 100 timeline requests and status updates every hour? Or 1.5 per
 minute? or what? My app does automatically slow down the timeline
 refresh after getting a 400 error, and it sets it back to 20 per hour
 when it stops getting 400 errors.

Re: Problem with replying to messages

[Ed Finkler]

Yes, it's because I approved them. 8)

On Tue, Oct 14, 2008 at 8:25 PM, jim.renkel [EMAIL PROTECTED] wrote:

 OK, the replies and this new post are now visible some 15 minutes
 later. I guess I just wasn't patient enough. :-)

 Thanks,

 Jim Renkel

 On Oct 14, 7:09 pm, Ed Finkler [EMAIL PROTECTED] wrote:
 Posts from new users are moderated. Spam is just too bad on Google
 Groups now (I've seen it on several others I am on or maintain).

 --
 Ed Finklerhttp://funkatron.com
 AIM: funka7ron
 ICQ: 3922133
 Skype: funka7ron

 On Tue, Oct 14, 2008 at 8:05 PM, jim.renkel [EMAIL PROTECTED] wrote:

  I've tried replying to several messages in the twitter API discussion
  threads, get a reply that the post was successful, but the message
  doesn't show up.

  I've done this many other times in other Google groups with no
  problem. Any ideas what I might be doing wrong here? Anybody else
  seeing this?

  Thanks in advance,

  Jim Renkel