[twitter-dev] since_date or max_date or until or since for user_timeline
Searching through the group, there have been a few requests for this functionality, with the only 'official' reply coming from al3x in a thread back in 2007 that he'd certainly hope to have it in by the end of the year. Would it be possible to get someone from the team to say "yes, we really want to add this too", or a "keep dreaming, pal"? Primarily, this would save from having to page until I've got all the statuses for a given timespan. It's fine if the official answer is that you're just supposed to keep on paging, I guess I'd just like to know. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] OAuth pin only works first try?
I'm not sure if this is a problem with my code, the libraries I'm using (perl Net::Twitter::Role::OAuth) or something else entirely. My program gets a request token, shows the user the website URL, and waits for the pin. If they enter the pin correctly, all it well, I get an access token. If they enter the pin wrong, I get 401 Unauthorized - which is expected. But if they then try again to enter the pin, even the correct pin shows as unauthorized. Is there a way to give the user a second chance to get the pin right, or do they have to go to the website and get a new one? Is there some way to validate the pin before using it?
[twitter-dev] Re: OAuth pin only works first try?
I thought it might be by design, but couldn't find that mentioned anywhere. I guess it is necessary to prevent apps guessing the pin, though it may be annoying for users.
[twitter-dev] Should consumer token be kept secret?
I'm almost ready to release a desktop app using OAuth. It's written in Perl, so anyone can read the source. Should I remove my consumer token and secret and make people get their own? Or is it safe to distribute?
[twitter-dev] Re: Should consumer token be kept secret?
After reading that thread, it seems there is no good solution :( On Jul 10, 1:17 pm, Howard Siegel wrote: > There was just a long thread discussing these sorts of security issues. > > The thread title is "Security Best Practices" and is at > <http://groups.google.com/group/twitter-development-talk/browse_thread... > > > > - h > > On Fri, Jul 10, 2009 at 10:05, Grant Emsley wrote: > > > I'm almost ready to release a desktop app using OAuth. It's written > > in Perl, so anyone can read the source. > > > Should I remove my consumer token and secret and make people get their > > own? Or is it safe to distribute?
[twitter-dev] Re: Just launched TwitStat.us...
It's a cool little program. With the rate limiting - the requests should come from the viewer's IP address, so rate limiting shouldn't be a problem. At worst, individual users viewing it 20,000 or whatever time an hour would see an error, everyone else would be fine.
[twitter-dev] Re: to send messages or tweets to twitter is that possible
http://apiwiki.twitter.com/Libraries The very first category is for flash... On Jul 13, 2:56 am, nite21 wrote: > hi all > i want to send data from flash to twitter > is that possible > > thanks
[twitter-dev] Re: Trying to post but my account is not posting duplicate posts
I think the limit is only on the API. I suppose there are/were conditions where duplicates would get posted, and this prevents that from happening. Easiest thing to do: Have your program put a timestamp in the message, so instead of "You have a new update", put "11:57:01 You have a new update"
[twitter-dev] Re: OQ Codes as tweets
So you want to encode text as an image...then translate the image to text, send through twitter, translate the text to an image...and then decode the QR code back to text? I have no idea why you would want to do that. There must be an easier way. Convert the QR code back to text and send via twitter, or something. It probably wouldn't work anyways - the image would be too degraded (judging by the picture in your first link) for the QR code to be recognized properly. On Jul 13, 12:14 pm, Peter Denton wrote: > Hello, > I remember reading the discussion of sending images through tweets, e.g. > quasimondo's post on flickr > athttp://www.flickr.com/photos/quasimondo/3518306770/ > > I am wondering if people think you could do this successful with a QR > code?http://code.google.com/apis/chart/types.html#qrcodes > > -Peter
[twitter-dev] Re: OAuth necessary when I don't need to take over people's accounts?
It will improve the security of your account since it won't be sending username/password in plaintext anymore. It's not that much more complicated to do. In fact, if you are just doing it for one account, you can run the sample code for oauth, write down the access token and secret, and just hard code them into your app instead of putting in the username and password.
[twitter-dev] Re: Too Many Requests for a specific user ....
On Jul 26, 10:06 pm, Francis Shanahan wrote: > I realise there are limits on the number of times an application can > call into Twitter in a given time period. > > In the course of my testing though I tend to fire off a lot of > requests, nothing crazy just probably 1 per minute as I'm clicking > through my tests. > > Sometimes when I'm testing oAuth Login and logging in/out of the > application, and going back and forth with the Grant/Deny page I am > experiencing 403 Unauthorized errors with the following data in the > response > > /account/ > verify_credentials.xml?oauth_consumer_key=[removed] > &oauth_nonce=7959883&oauth_signature_method=HMAC- > SHA1&oauth_timestamp=1248659818&oauth_token=[removed] > &oauth_version=1.0&oauth_signature=TH > %2bFof7ErcFdH6XgVgPeou174yI%3d > Too many requests in this time period. Try again later. > > > This error is just given for my account, other users don't get this > error. I can log in from the site with another user without issue. > > So given that I'm not making that many requests and can trigger this > with just manual clicking, how many are allowed for a given user? I believe the limit is 15/hr, though they may be changing that.
[twitter-dev] Re: DM-based services
Require people to follow you before they can use the service? On Jul 27, 10:10 am, Andres B wrote: > Hi, I'm having some trouble sending messages to the group, so I'll > break it down in a couple different messages. > > I developed muuter.com and my users can send mute commands through DM > i.e. "d muuter someone 8 h". > > For this to work, @muuter needs to follow every user, and right now I > can't because I'm hitting a follow ratio, at 130 followers vs 800 > following. Is there a best practice to offer services through DM? > > Thanks in advance. > > Best, > Andres B > @andresb
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth isn't perfect yet. However, it is better from one stand point: If I sign up for a website or program with my twitter password, and it does bad things, I have to change my password in EVERY twitter program I use. With OAuth, I can just block your app. On Jul 28, 9:08 am, Duane Roelands wrote: > To be fair, OAuth is better for the user, security-wise, because they > never have to provide their Twitter credentials to your application. > Basic Auth also provides no way to know that the application is > actually who it says it is. OAuth is far from perfect on this front, > but it's light-years ahead of Basic. > > I'm just as agitated about this as anyone, because I think that > Twittter's behavior in this specific instance has been sub-par. > However, OAuth is still far more secure than Basic Auth > > On Jul 28, 7:27 am, chinaski007 wrote: > > > Let's be honest... > > > The end-result for third-party developers using OAuth appears to be > > fewer sign-ups, less reliability, more complexity, and potentially > > less security. > > > Google Optimizer reveals that users are more likely to sign-up for > > Basic Auth than OAuth. That's just fact. Test it for yourself to > > confirm. > > > I suppose this is not so weird. Users are accustomed to giving user/ > > pass information even to "foreign" apps. It is far more disruptive > > and invasive for them to go to some bizarre Twitter screen asking them > > to "approve an app". To the average user, what does that mean? (And, > > heck, it may even require more steps if they have to login again to > > Twitter.) > > > In terms of reliability, Twitter OAuth was down for days several weeks > > ago. Tonight yet another unannounced change occurred that broke major > > code libraries. Meanwhile, Basic Auth has been plugging along just > > fine and dandy... > > > So what IS the benefit of OAuth? > > > It doesn't benefit developers as you will likely get more sign-ups > > with Basic Auth and Basic Auth is far, far easier to setup. Sure, > > OAuth might satisfy some power users hungry for security... > > > But is OAuth even more secure than Basic Auth? > > > Perhaps not. After all, tonight's fix was for an OAuth security flaw > > known for at least 10+ days (judging by tweets to @twitterapi) that > > allowed for potential impersonations of credentialed users. > > > On the heels of Twitter's (unofficial) assurance of better > > communication with developers, this sort of unannounced change is > > distressing. What's next? (Have Labor Day Weekend plans? You might > > want to cancel those... just the right time for Twitter to make an > > unannounced API change!) > > > As for us, we are in the strange position of deprecating OAuth in > > favor of Basic Auth. > > > Weird, eh?? > > > Okay, we are not totally deprecating OAuth, but we are advising users > > that Basic Auth is far more robust and reliable. > > > And so our message to new developers: avoid OAuth like the plague. If > > you must, offer it. But let Basic Auth be your backbone: more > > reliable, more sign-ups, simpler, and probably just as secure. (Just > > look at Google Code bug reports about OAuth to get a sense of > > reliablity.) > > > (Okay, okay, this post was written at 4am after a workday that started > > at 8am, and after Twitter introduced this new change at 5pm... (hey > > Twitter, can you introduce major new changes EARLIER in the day so we > > can react!?!?)... it still doesn't excuse Twitter's continued > > disregard for the small-to-medium size developer.)
[twitter-dev] Re: Updating the APIs authentication limiting policy
Locked out of authenticated resources for that account, or will that IP not be able to login to any account? On Jul 29, 1:14 pm, Doug Williams wrote: > Ray,For clarity, we will roll back the current restriction of 15 calls per > user per hour to account/verify_credentials, and implement the proposed > scheme: > > > > > ... we will limit the total number of unsuccessful > > attempts to access authenticated resources to 15 an hour per user per IP > > address. If a single IP address makes 15 attempts to access a > > protected resource unsuccessfully for a given user (as indicated by an > HTTP 401), > > then the user will be locked out of authenticated resources from that > > IP address for 1 hour. > > Thanks, > Doug > > On Wed, Jul 29, 2009 at 9:51 AM, Ray wrote: > > > Doug, > > > I'm in a similar situation as that voiced by TinBlue. This change has > > affected our iPhone App. We also want to encourage you to rollback > > this change ASAP. > > > When you say "This approach is what we are going to take.", do you > > mean rolling back the fix so as not to affect multiple, successful, > > authorized logins? I'm hopeful that "this approach" means that our > > apps will not be affected yet again by changing to a new auth > > approach. > > > I appreciate you all keeping this thread informed. > > > Ray > > > On Jul 27, 11:23 am, Doug Williams wrote: > > > Thanks to everyone who has contributed feedback. This approach is what we > > > are going to take. > > > Alex will be making this change shortly. I will update this thread when > > > there is timeframe to share. > > > > Thanks, > > > Doug > > > > On Mon, Jul 27, 2009 at 7:52 AM, TinBlue wrote: > > > > > What is happening? > > > > > This rollback is taking far too long for something that has affected a > > > > lot of people! > > > > > On Jul 25, 2:32 pm, Dewald Pretorius wrote: > > > > > Doug, > > > > > > I would prefer to adopt OAuth instead of writing code for Basic Auth. > > > > > > So, you guys need to move OAuth out of public beta into full > > > > > production sooner rather than later. :-) > > > > > > I manage 100,000+ Twitter accounts, and I simply cannot take on the > > > > > support workload of answering user tickets when there's a snag with > > > > > OAuth beta. > > > > > > I monitor these forums and the API Issues and still see too many > > OAuth > > > > > issues being reported to give me a level of comfort that I can safely > > > > > switch over to OAuth. > > > > > > On Jul 24, 5:46 pm, Doug Williams wrote: > > > > > > > Well said Joshua. > > > > > > > Dewald, you have identified the risk of using basic authentication. > > If > > > > > > your users being locked out due to malicious behavior, you should > > > > > > either implement further user-level rate limiting on your side or > > > > > > adopt OAuth. > > > > > > > Are there any other glaring omissions in our thinking or should we > > > > > > proceed with this as our solution? > > > > > > > Thanks, > > > > > > Doug > > > > > > > On Fri, Jul 24, 2009 at 11:08 AM, Joshua Perry > > wrote: > > > > > > > > Jim's concern is valid, fortunately OAuth is immune to > > brute-force > > > > attacks > > > > > > > once the access key has been issued to an application. For this > > > > reason alone > > > > > > > I would urge people to switch to OAuth if at all possible. I > > would > > > > hope > > > > > > > (and assume) that if login attempts for an account are locked out > > > > that a > > > > > > > user would still be able to successfully use an already > > authorized > > > > OAuth > > > > > > > driven application. > > > > > > > > Unfortunately allowing a successful un/pw login while an account > > is > > > > locked > > > > > > > out even when the correct password is presented effectively > > bypasses > > > > the > > > > > > > whole reason for a lockout in the first place, preventing > > brute-force > > > > > > > password attempts. If an attacker used a dictionary or > > brute-force > > > > attack > > > > > > > and the account was locked out after 15 attempts, then they could > > > > continue > > > > > > > trying even though the system replied "locked out"; if they > > > > eventually sent > > > > > > > the correct password it would just bypass the lockout and they > > would > > > > then > > > > > > > know the correct password. > > > > > > > > Perhaps Twitter could implement a selective captcha, I know they > > are > > > > > > > annoying but if executed properly it could be effective > > protection > > > > against > > > > > > > brute-force and dictionary attacks. Say after 3 or 4 failed > > attempts > > > > without > > > > > > > a captch the API would then include a captcha image URL in it's > > > > response > > > > > > > that the application would then need to show to the person and > > > > include the > > > > > > > user's response with the next authentication attempt as a header > > or > > > > POST > > > > > > > variable. The site stackoverflow.com does this to great effect, > > if > > > > you > > >
[twitter-dev] Re: Updating the APIs authentication limiting policy
Perhaps a better approach to the lockout: Lock the account for x minutes after 15 *unique* bad passwords. So if the user changes their password, and another program keeps trying with their old password, that only counts as 1 attempt. It still only gives them 15 guesses, but would cause fewer lockouts because of badly behaved programs like the spam bots mentioned above.
[twitter-dev] Non-Developer RSS Feeds
Now that OAuth is here, how will the general public get access to Twitter RSS feeds? Since Basic auth has been disabled they seem unusable. Thanks, Grant -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Twitter List
Is there anyone that can help me with the Twitter API? I am creating an app with loads of info for users, but I would love to include a screen that displays the tweets of lists that I have created. It's not a place for users to post their own tweets, just a reader. The user would first see a screen of the possible lists to read, then display the chosen list. It would be so simple if it were a simple URL of that page but it's not. Id like it to display similar to twitters mobil app for lists; the tweet'ers aviator, tweet, and timeline. RSS doesn't fit the bill for the look I want. Looking for the exact look the twitter app displays for a given list, thats it. It seems like it should be simple coding but I have not been able to find the answer. Anyone have this expertise? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Hovercards with blogger.js?
I'm using the blogger.js script on my site to display my latest tweets, but the usernames are hrefs, and @anywhere doesn't seem to recognize them and add a hovercard for them (it works on the rest of my site)
