[twitter-dev] Re: Always returned "Failed to validate oauth signature and token"
Thanks a lot! After fixing this upper case issue and I also found there is a misunderstanding about base string URL encoding, the request token can be returned now. Thanks everyone ~ On Jul 6, 1:04 pm, JDG wrote: > from the oauth core section on parameter encoding: > > Hexadecimal characters in encodings MUST be upper case.[1] > > Your string has %2b and %3d. You should see if that's causing it. > > [1]http://oauth.net/core/1.0/#signing_process > On Sun, Jul 5, 2009 at 21:01, muramastu wrote: > > > Thanks~ > > I've also tried "GET" method, however, it still returned same message. > > The following is the data: > > > #Base String: > > GET%26HTTP://twitter.com/oauth/request_token%26oauth_consumer_key > > %3d6RfEXDtG3UBD1JFpUCPtg%26oauth_nonce > > %3d1246848991%26oauth_signature_method%3dHMAC-SHA1%26oauth_timestamp > > %3d1246848991%26oauth_version%3d1.0 > > > #Signature: (after HMAC-SHA1 encrypted, Base64 encoding and URL > > encoding) > > MXMwzBjqXWuNZrGpYi2OoBS%2bEdY%3d > > > #HTTP request header I sent: (use GET as the HTTP method, > > HttpSendRequest() ) > > Authorization: OAuth > > oauth_consumer_key="6RfEXDtG3UBD1JFpUCPtg",oauth_signature_method="HMAC- > > SHA1",oauth_signature="MXMwzBjqXWuNZrGpYi2OoBS%2bEdY > > > %3d",oauth_timestamp="1246848991",oauth_nonce="1246848991",oauth_version="1.0" > > > On Jul 3, 10:19 pm, Abraham Williams <4bra...@gmail.com> wrote: > > > Based onhttp:// > > apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_t... > > > should be using a GET. > > -- > Internets. Serious business.- Hide quoted text - > > - Show quoted text -
[twitter-dev] Re: oAuth company name
Peter, Verification of companies is in the future for Twitter. There is no publicly released ship date to mention but it is safe to say that within the next year that this should be coming to the service. Thanks, Doug On Sat, Jul 4, 2009 at 4:47 PM, JDG wrote: > i think the only thing that would keep you would be a sternly-worded letter > from Microsoft's legal team to both you and Twitter. > > > On Sat, Jul 4, 2009 at 16:08, Peter Denton wrote: > >> Hey all, >> Not trying to ask the team an annoying question, but is there anything to >> keep me from typing in Microsoft Corp to company name in oAuth for an >> application registration? >> Someone asked me this and I thought I would ask the group. Is there going >> to be a "validated account" badge for apps? >> >> Thanks >> Peter >> > > > > -- > Internets. Serious business. >
[twitter-dev] Re: from API
Sorry, didn't mean to reply to you specifically. On Jul 5, 6:42 pm, Chad Etzel wrote: > On Sun, Jul 5, 2009 at 1:32 AM, Harrison wrote: > > > This isn't a "loophole." It's a documented function of posting the > > tweet source. It just so happens that 'web' is a valid source > > parameter. > > Exactly. That's why I put it in "quotes." > > -Chad > from email
[twitter-dev] Re: Stream API : Tracker and Follow together
Yes, you can use two Streaming API methods from the same IP address. As you already know, it will require two accounts when connecting simultaneously. Thanks, Doug On Sun, Jul 5, 2009 at 9:33 PM, Cary Knoop wrote: > > I am writing an application and ideally I like to use Tracker to > follow searches and Follow to follow certain users. Is it allowed to > use Tracker and Follow using the same IP address with two different > user accounts? > > > Cary >
[twitter-dev] Re: Taken Usernames
Josh, Check out our help article on user names [1]. If you own the trademark, please submit a ticket through the support site and explain your situation. They have a 10 day backlog so please be patient. 1. http://help.twitter.com/forums/10713/entries/14608 Thanks, Doug On Fri, Jul 3, 2009 at 12:27 PM, Stuart wrote: > > 2009/7/3 Josh : > > > > We own a business and are interested in setting up a Twitter account > > in the name of our business. We also own the copyright for this name. > > Unfortunately the name has been taken. However, the account has been > > inactive for the last 6 months. What are the steps we need to go > > through to get this user name? > > Email usern...@twitter.com (that's actually "username" not the > username you're after) with the details. > > -Stuart > > -- > http://stut.net/projects/twitter >
[twitter-dev] Re: Need extra parameters
Try the page parameter. Here's the documentation to get you started [1]. 1. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-user_timeline Thanks, Doug On Fri, Jul 3, 2009 at 10:39 AM, Ravinder Chopra < ravinderc.impi...@gmail.com> wrote: > > hi > > > I think i need extra parameters in this api > http://twitter.com/statuses/user_timeline/raj.xml?count=200 > > like count , i need a parameter which is used to extend this value > means > > In first call 200 > in next call next 200 > > First call > http://twitter.com/statuses/user_timeline/raj.xml?start=0&count=200 > > Next call :: I rise the value of start so that i will send me next > 200 records > > http://twitter.com/statuses/user_timeline/raj.xml?start=200&count=200 > > Thanks > Ravinder >
[twitter-dev] Re: daily follow/unfollow/update limit
Hi all -- The current update/follower/unfollower limits are not programmatically accessible for a given account in large part because there is little real value. Most use cases which find such information valuable is behavior that we do not feel benefits Twitter as a whole. Do you have a non-spammy app or app that does not contribute to follower churn where a limits method would help? If so, please share. Thanks, Doug On Fri, Jul 3, 2009 at 6:10 PM, Chris Latko wrote: > > Yes, > > My users are in the same predicament. They seem to hit a daily limit of 200 > follows. My personal account has a higher limit of 500. No DMs are sent > through any of these accounts. Is there something I'm missing? > > Thank you, > > Chris > > > > On Jul 3, 2009, at 12:00 PM, bakedpotato wrote: > > >> Doug, >> >> I have been told by support (Lukester) that my account was exceeding >> following limits of over 1000/day. 5 days ago I disabled SocialToo >> which was set to follow 100/day. I have since tried to add followers >> (the last 4 days) yet have been restricted do so at all. >> >> Can you please help me understand what I can do to add followers >> again? >> >> Thanks for your attention. >> >> On Jul 2, 8:13 am, Doug Williams wrote: >> >>> It initially seemed like you were asking about the update limit but now >>> you >>> are talking about following limits. Can you be more specific on the >>> behavior >>> you are seeing and why you feel it is an issue? We can argument the >>> documentation to clear the confusion but I'm not following your exact >>> problem. >>> >>> Thanks, >>> Doug >>> >>> On Thu, Jul 2, 2009 at 6:00 AM, Dewald Pretorius >>> wrote: >>> >>> I have noticed the same thing, and there is no predictable pattern to it. >>> >>> The API kicks back the limit exceeded message on numbers far below 1,000. >>> >>> The same goes for DMs. I've seen a person being limited after 200 DMs have been sent. >>> > -- > Chris Latko > www.latko.org > @clatko > > > >
[twitter-dev] Re: Retrieving a list of followers and/or friends for an arbitrary user...
On Sun, Jul 5, 2009 at 10:33 PM, kmslogic wrote: > Along the lines of retrieving a list of an arbitrary user's friends or > followers--is there any way to convert the list of numbers into screen > names or user names without calling the /users/show.xml?id=x > function over and over? Even for a modest friends or followers list > it seems like you'd run into the rate limiter immediately just to > produce a list of names... see http://bit.ly/11hbry apply for whitelisting. build a local cache. yes, it's less than ideal. -damon
[twitter-dev] Re: Always returned "Failed to validate oauth signature and token"
from the oauth core section on parameter encoding: Hexadecimal characters in encodings MUST be upper case.[1] Your string has %2b and %3d. You should see if that's causing it. [1] http://oauth.net/core/1.0/#signing_process On Sun, Jul 5, 2009 at 21:01, muramastu wrote: > > > Thanks~ > I've also tried "GET" method, however, it still returned same message. > The following is the data: > > #Base String: >GET%26HTTP://twitter.com/oauth/request_token%26oauth_consumer_key > %3d6RfEXDtG3UBD1JFpUCPtg%26oauth_nonce > %3d1246848991%26oauth_signature_method%3dHMAC-SHA1%26oauth_timestamp > %3d1246848991%26oauth_version%3d1.0 > > #Signature: (after HMAC-SHA1 encrypted, Base64 encoding and URL > encoding) > MXMwzBjqXWuNZrGpYi2OoBS%2bEdY%3d > > #HTTP request header I sent: (use GET as the HTTP method, > HttpSendRequest() ) > Authorization: OAuth > oauth_consumer_key="6RfEXDtG3UBD1JFpUCPtg",oauth_signature_method="HMAC- > SHA1",oauth_signature="MXMwzBjqXWuNZrGpYi2OoBS%2bEdY > > %3d",oauth_timestamp="1246848991",oauth_nonce="1246848991",oauth_version="1.0" > > > On Jul 3, 10:19 pm, Abraham Williams <4bra...@gmail.com> wrote: > > Based onhttp:// > apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_t... > > should be using a GET. > -- Internets. Serious business.
[twitter-dev] Stream API : Tracker and Follow together
I am writing an application and ideally I like to use Tracker to follow searches and Follow to follow certain users. Is it allowed to use Tracker and Follow using the same IP address with two different user accounts? Cary
[twitter-dev] Stream API : Tracker
Unlike the wiki documentation searching for instance for the keyword Tennis does not give results that include keywords #Tennis or @Tennis. Is this as designed or is this a bug? Cary
[twitter-dev] Re: Retrieving a list of followers and/or friends for an arbitrary user...
Along the lines of retrieving a list of an arbitrary user's friends or followers--is there any way to convert the list of numbers into screen names or user names without calling the /users/show.xml?id=x function over and over? Even for a modest friends or followers list it seems like you'd run into the rate limiter immediately just to produce a list of names...
[twitter-dev] Re: Always returned "Failed to validate oauth signature and token"
Thanks~ I've also tried "GET" method, however, it still returned same message. The following is the data: #Base String: GET%26HTTP://twitter.com/oauth/request_token%26oauth_consumer_key %3d6RfEXDtG3UBD1JFpUCPtg%26oauth_nonce %3d1246848991%26oauth_signature_method%3dHMAC-SHA1%26oauth_timestamp %3d1246848991%26oauth_version%3d1.0 #Signature: (after HMAC-SHA1 encrypted, Base64 encoding and URL encoding) MXMwzBjqXWuNZrGpYi2OoBS%2bEdY%3d #HTTP request header I sent: (use GET as the HTTP method, HttpSendRequest() ) Authorization: OAuth oauth_consumer_key="6RfEXDtG3UBD1JFpUCPtg",oauth_signature_method="HMAC- SHA1",oauth_signature="MXMwzBjqXWuNZrGpYi2OoBS%2bEdY %3d",oauth_timestamp="1246848991",oauth_nonce="1246848991",oauth_version="1.0" On Jul 3, 10:19 pm, Abraham Williams <4bra...@gmail.com> wrote: > Based > onhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_t... > should be using a GET.
[twitter-dev] Using MagpieRSS Authentication with the Twitter API
I'm a relative beginner using MagpieRSS with PHP to present Twitter RSS feeds on my web-page. I've had no problems with regular feeds, but I'm struggling to get authenticated feeds to work. I'd be very grateful if someone could explain very simply how to implement the HTTP authentication to work with MagpieRSS for me.
[twitter-dev] Re: OAuth Desktop Application Changes - Incompatibility Alert
Would it be possible to make the last number of the PIN a mod 10 checkdigit? This would allow applications to validate the PIN without having to do a hit to the oAuth webservice, say in the case that the user accidentally missed one of the digits when copying them from the page, or perhaps the user tried to memorize the number and entered it incorrectly. http://en.wikipedia.org/wiki/Luhn_algorithm Josh Matt Sanford wrote: Hello, One of the things we've been saying about OAuth all along is that we'll be improving the desktop application experience. Well, the time is here for the first re-visit. As part of out changes for OAuth version 1.0a [1] I have been looking at how this is going to work and there is going to need to be a change that will not be backward compatible. Some of this is already coded and waiting to go, and some of it is in-progress. I expect we will deploy this the end of next week or the beginning of the following one in order to allow you to have a minimum of 7 days to make changes. These only effect desktop applications so the majority of OAuth applications are not affected. Here are the expected changes: 1. If your application is registered as a desktop application callbacks will not be supported. *Workaround*: Visit your application details page to change the application type and provide a default callback URL. *Details:* Dynamic callbacks are currently disabled for all applications. With changes for 1.0a [1] will re-enable dynamic callback support but applications registered as 'desktop' will not support this. When requesting a request token the you will get an error saying that callbacks are not supported in desktop applications. This is to prevent stealing of tokens created with a PIN (see #2) by webapps re-using the freely available desktop consumer key and secret. 2. If your application is registered as a desktop application there will be a PIN the user must enter in your application * Details*: In the current code desktop applications end in a dead-end page. This new flow will give the user a PIN that they enter in the application and that must be provided to swap a request token for an access token. This will help secure tokens for desktop applications since the security of the consumer key and secret cannot be relied upon. *Feedback: *We are planning to make this a required step but I am open to discussion if anyone feels there is a compelling case for desktop applications without a PIN. Email me directly with feedback. 3. If your application is registered as a desktop application you will not be able to use the 'Sign in with Twitter' functionality. *Details:* 'Sign in with Twitter' requires a callback URL which will not be allowed per #1 above. We're working to make sure we provide OAuth interfaces wherever possible. Desktop applications was a definite problem that needed some fixing. Close behind that is mobile web which is currently being looked at by a group reviewing all of m.twitter.com. If you have any objections to the changes above, or some reason that you don't think it will work, please feel free to email me directly. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - OAuth spec 1.0a addresses problems with oauth_callback and should be finalized very soon. More info at http://groups.google.com/group/oauth/browse_frm/thread/b0345ad5b5466587
[twitter-dev] Re: OAuth Desktop Application Changes - Incompatibility Alert
Can we change the wording on the PIN page of the desktop workflow? Currently it is worded as follows: You've successfully granted access to ! Enter the following PIN when prompted by Obviously a desktop application has no idea that this flow actually completed, and hence has no way to "prompt" the user to do anything. A user could sit there for awhile waiting for a prompt. I think it would be more clear if it was worded something along the lines of: You're almost done pairing with your Twitter account! Simply return to and enter the following PIN to complete the process. Josh Matt Sanford wrote: Hello, One of the things we've been saying about OAuth all along is that we'll be improving the desktop application experience. Well, the time is here for the first re-visit. As part of out changes for OAuth version 1.0a [1] I have been looking at how this is going to work and there is going to need to be a change that will not be backward compatible. Some of this is already coded and waiting to go, and some of it is in-progress. I expect we will deploy this the end of next week or the beginning of the following one in order to allow you to have a minimum of 7 days to make changes. These only effect desktop applications so the majority of OAuth applications are not affected. Here are the expected changes: 1. If your application is registered as a desktop application callbacks will not be supported. *Workaround*: Visit your application details page to change the application type and provide a default callback URL. *Details:* Dynamic callbacks are currently disabled for all applications. With changes for 1.0a [1] will re-enable dynamic callback support but applications registered as 'desktop' will not support this. When requesting a request token the you will get an error saying that callbacks are not supported in desktop applications. This is to prevent stealing of tokens created with a PIN (see #2) by webapps re-using the freely available desktop consumer key and secret. 2. If your application is registered as a desktop application there will be a PIN the user must enter in your application * Details*: In the current code desktop applications end in a dead-end page. This new flow will give the user a PIN that they enter in the application and that must be provided to swap a request token for an access token. This will help secure tokens for desktop applications since the security of the consumer key and secret cannot be relied upon. *Feedback: *We are planning to make this a required step but I am open to discussion if anyone feels there is a compelling case for desktop applications without a PIN. Email me directly with feedback. 3. If your application is registered as a desktop application you will not be able to use the 'Sign in with Twitter' functionality. *Details:* 'Sign in with Twitter' requires a callback URL which will not be allowed per #1 above. We're working to make sure we provide OAuth interfaces wherever possible. Desktop applications was a definite problem that needed some fixing. Close behind that is mobile web which is currently being looked at by a group reviewing all of m.twitter.com. If you have any objections to the changes above, or some reason that you don't think it will work, please feel free to email me directly. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - OAuth spec 1.0a addresses problems with oauth_callback and should be finalized very soon. More info at http://groups.google.com/group/oauth/browse_frm/thread/b0345ad5b5466587
