[twitter-dev] Twitter Search source: operator stopped working for sources with an embedded dot?
Matt, Doug, I will often use the following query at http://search.twitter.com to monitor links posted with my Social.com application: j.mp source:social.com I noticed over the last few weeks that sometimes the source: operator would stop working altogether for all applications, but usually starts working again.For the past many days I have been unable to get it to work with the above query, though it does seem to work for other applications without a dot in the name. Has support for applications with a dot in the name been dropped (hoping this isn't the case)? I get the error: Unknown source 'social.com' FYI - there are posts going to Twitter with via Social.com Thanks, Scott
[twitter-dev] Re: Is it OK to store token in COOKIE?
An alternative is to encrypt the token secret. Keep the encrypted secret on the server and the encryption key in a cookie. - Scott On Feb 17, 9:27 am, John Meyer john.l.me...@gmail.com wrote: On 2/17/2010 5:32 AM, Dmitri Snytkine wrote: Just wondering, is it a bad practive for a web-based app to store user's token and secret in cookies? This would of cause simplify and speed up the login, but is it a security risk? When you boil it down, everything done to increase accessibility is a security risk. I would think that if you keep your consumer key pair on the server there is little problem with this.
[twitter-dev] Is verify_credentials rate limited?
I was wondering what the official stance was on rate limiting of verify_credentials? According to the API documentation it isn't (API rate limited = false): http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verify_credentials I did however note that it was rate limited during the DDoS attack earlier in the year: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/2d68c74567bc9809/ed0c484f66809740?hl=enlnk=gstq=verify_credentials+rate+limiting#ed0c484f66809740 I also saw indications of rate limiting as recently as Oct 3: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/e4052d52e722378a/0f22a5aaf424745d?hl=enlnk=gstq=verify_credentials+rate+limiting#0f22a5aaf424745d Just trying to plan ahead and not assume anything ... Thanks, Scott
[twitter-dev] If you see 417 Expectation Failed this post might help
I started to occasionally get a 417 response from Twitter when my
application was using cURL to fetch an OAuth Request Token.
The response would contain
417 Expectation Failed
The expectation given in the Expect request-header field could not be
met by this server.
The client sent
Expect: 100-continue
but we only allow the 100-continue expectation.
I found the answer here:
http://www.shoemoney.com/2008/12/29/lib-curl-twitter-api-expect-100-continue-pain-and-how-to-fix-it/
I thought it would be useful to post it to the group here in case
anyone else is searching these posts for a reference to this issue.
Why did I get the 417 response?
Apparently cURL started adding the header Expect: 100-continue when
my POST exceeded 1024 bytes.
Why was my POST so large?
I was specifying a callback URL with some long query arguments.
What was the quick fix?
In Perl, the solution was to add an empty Expect header:
my @myheaders=(
Expect:
);
$curl-setopt(CURLOPT_HTTPHEADER, \...@myheaders);
The link I referenced above provided the PHP solution:
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));
Hopefully this might save someone a few hours down the road ...
- Scott
@scott_carter
[twitter-dev] Tutorial article posted - Twitter OAuth using Perl
I just posted an article that goes into quite a bit of detail about how to create your own Twitter OAuth solution using Perl. http://www.bigtweet.com/twitter-oauth-using-perl.html I included quite a few code samples and several references. Hopefully this might save a fellow Perl hacker some time in putting together their own implementation. BTW - are there any fellow Twitter Perl developers in the Boston area? - Scott @scott_carter
[twitter-dev] URI Escape fix for OAuth - correct usage of uri_escape() with Perl
This post is geared toward Perl implementations of OAuth, though it may shed some light on recent URI escape problems in other languages as well. use Encode qw(encode); use URI::Escape; I previously had been escaping my parameters with a call such as: my $value = uri_escape(encode(UTF-8,$param)); The encode() call was encoding the $param as UTF-8 octets before percent encoding with uri_escape(). The use of uri_escape() above is NOT correct to meet the requirements of the OAuth spec. The following is the explanation and fix: # OAUTH spec URI encoding # = # # http://oauth.net/core/1.0a#encoding_parameters # with reference to # http://tools.ietf.org/html/rfc3986#section-2.3 # # 5.1. Parameter Encoding # # All parameter names and values are escaped using the [RFC3986] # percent-encoding (%xx) mechanism. Characters not in the unreserved character # set MUST be encoded. Characters in the unreserved character # set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. # Text names and values MUST be encoded as UTF-8 octets before percent-encoding # them per [RFC3629] # # unreserved = ALPHA, DIGIT, '-', '.', '_', '~' # # # URI::Escape # = # http://search.cpan.org/~gaas/URI-1.38/URI/Escape.pm # uri_escape() by default encodes # ^A-Za-z0-9\-_.!~*'() # # We must subtract from this the reserved characters: ! * ' ( ) # ^A-Za-z0-9\-_.~ # The correct assignment in Perl is thus: my $value = uri_escape(encode(UTF-8,$param),^A-Za-z0-9\-_.~); I've tested this and it fixed the problems I was having sending characters ! * etc. I suspect percent encoding in other languages may need a similar implementation. - Scott @scott_carter http://www.bigtweet.com/
[twitter-dev] Counting the bytes in Persian text (and other non English unicode)
One of my users mentioned that my client application was much more conservative in counting non English unicode bytes (specifically Persian) than Twitter itself. I've looked over the following thread and all the other threads referenced within without discovering a good answer: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a1a74365aa6827e7/4a45daee5a993e47 I've noticed a couple different behaviors. With simple Unicode (smiley face, arrow, etc), the Twitter Web interface apparently counts each character as 1 byte when displaying the count. Posting a long string of these however can lead to truncation. It seems perhaps that the Twitter Javascript is not making an attempt to accurately count Unicode? With Persian unicode, the Twitter web interface seems to allow a post of an amount of text much greater than I would have expected. My user provided a sample here that I used to experiment with: http://bit.ly/1LDsVJ I'm using Javascript code based on the method described here: http://www.inter-locale.com/demos/countBytes.html Does anyone have a more accurate counting method in Javascript that might be better with all types of Unicode? Thanks, - Scott @scott_carter
[twitter-dev] Sign in with Twitter - Flow chart error?
I am using as a reference the Sign in with Twitter documentation at: http://apiwiki.twitter.com/Sign-in-with-Twitter When I issue an authenticate call to: https://twitter.com/oauth/authenticate?oauth_token=request_token The callback I get is: callback_url?oauth_token=request_tokenoauth_verifier=verifier Questions: 1. This callback appears to be identical to the authorize response. Is there an error with the flow chart on the Sign in with Twitter page that indicates an authenticate callback will include the access token and token secret? 2. I understand that the advantage of using the authenticate process is that if a user has already authorized an application, they don't need to do it again. Is there any reason to use the authorize process instead? It seems that apps would benefit from always using the Sign in with Twitter authenticate flow. Thanks, - Scott
[twitter-dev] Bug with nonce value? Keeping it constant works for getting Request Token.
I just started to work toward incorporating OAuth with my application BigTweet using Perl. I have been following the excellent documenation at http://oauth.net. Jesse Stay's article at http://staynalive.com/articles/2009/05/19/social-coding-how-to-code-twitters-oauth-using-netoauth-and-perl/ was also very helpful. To the credit of the resources above, I was able to make a successful fetch of a Request Token on my first try.I began playing with the parameters to show that I could cause an error result. I discovered that I could keep the value of the nonce constant (I'm using a) and still fetch new Request Tokens. According to the spec at oauth.net it seems that the intent of the nonce was to be a unique random string for each request to help prevent replay attacks. Did I discover a bug? Thanks, - Scott @scott_carter http://bigtweet.com
[twitter-dev] OAuth: Screen name returned with access token - documented feature?
I noted that the screen name (and user id) are returned along with the Access token and secret. It this a documented feature that I can rely upon? The only related thread that I found on this topic was: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/8b24ab7dbb326d5f/10e6b73bd9fdce69 That thread was apparently referring to the callback after authorization and why screen_name and user_id were removed for security reasons. Matt mentioned that the verify_credentials method was the solution in that case. If I have the screen_name available with the Access token/secret, I don't see a need for calling verify_credentials at all in the process. I don't really need the screen name until after I exchange my request token for an access token. Can I rely on getting the screen_name this way? Am I missing another reason for needing to call verify_credentials? Thanks, - Scott Carter @scott_carter http://bigtweet.com
[twitter-dev] Can OAuth approval process work in an IFRAME?
I'm starting to look at the OAuth process and had a question for the OAuth folks at Twitter. My application BigTweet is invoked via a bookmarklet and displays as an IFRAME on any web page that a Twitter user happens to be browsing.Ideally I would like to be able to complete the entire OAuth process within the IFRAME (for initial login). I believe that Twitter recently added measures to prevent framing of their site to stop phishing attacks. Does this extend to the OAuth approval page? Could an exception be made for the OAuth page when invoked from a registered application presenting a valid Request Token? If so, could this be documented (perhaps in the OAuth Twitter FAQ)? The authorization page at Twitter appears to have a fairly small content section (with Deny/Allow buttons, etc), which could fit into a reasonably sized IFRAME. If you are agreeable to allow IFRAME support, would it be possible to standardize on content dimensions (for IFRAME sizing) and document this as well? Thanks for considering my request. Scott http://twitter.com/scott_carter
[twitter-dev] Re: Can OAuth approval process work in an IFRAME?
I think Ivan's suggestion could answer the concern about the case where a user needs to enter a username/password: If not signed in, a new window could load with the regular OAuth process. For the case where the user is already logged in, there doesn't appear to be any risk here. Consider the scenario where the IFRAME is populating a page from a site pretending to be Twitter with an Allow/ Deny button. By clicking Allow, nothing bad can happen. Twitter isn't Allowing anything in this case since it wasn't their page to begin with. FYI - I think my case is different than Ivan's since he is discussing a widget whereas my app lives entirely in the IFRAME. The callback from Twitter after authorization would simply cause the IFRAME to redirect back to a page on bigtweet.com where I could then present a different (logged in) view for the user. Joshua's suggestion would work, but providing IFRAME support with a callback URL would save the user two steps - needing to close the Authorization window, and clicking the Complete Connection button. Scott On Mar 20, 5:50 pm, Abraham Williams 4bra...@gmail.com wrote: If you have the approval process take place in the iframe there is no way to for the user to actually verify they are interacting with twitter. if they are not logged into twitter already you are then asking users to enter username/password on a potentially unsafe site and opening up to fishing. On Fri, Mar 20, 2009 at 16:29, Joshua Perry j...@6bit.com wrote: The interesting thing is, that you could omit the callback URL in your application registration with Twitter. On your site when the user clicks the connect twitter button you would go and grab a request token and pop a new window with that request token in the URI like usual. The user would click accept and since there is not a callback URL Twitter will say You can close this window and complete the Connect process. Waiting on your webpage would be the complete connection button which, when clicked, would request Twitter to convert the request token into an access token. Instead of popping a window I don't know why you couldn't load the Twitter authorization page into an IFrame, but the message to close this window may be a bit confusing to the user. This flow is the same as a desktop application has to use to accomplish an OAuth connection and should work the similarly well with a web application. Josh Ivan Kirigin wrote: I'd love to be able to do this also, and have mentioned it off the list. Imagine a Twitter Connect button, which would be a tiny iframe loaded from twitter.com. If signed in, the token exchange could take place right there. If not signed in, a new window could load with the regular OAuth process. The callback in the button would be to a tiny iframe acting as a confirmation of the success, loaded by the consumer. There is a diminished phishing risk, because the widget isn't asking for your password. Only the new window would. The only question is how the rest of the widget gets the notification that the OAuth access grant has taken place. My thought is that the widget could just ping the web service to see if things are integrated properly. Cross domain iframe communication is a HUGE pain in the ass. You can get around it if the twitter iframe loaded a designated hidden iframe from the 3rd party. Alternatively, you could ask the user to refresh the widget / bookmarklet. Generally, I'd like to see some standard buttons from twitter, so normalize the OAuth experience. You can see on the top of http://tipjoy.com a banner we made that uses twitter fonts and colors. Best, Ivan http://tipjoy.com ps check out our twitter payments api:http://tipjoy.com/api feedback welcome! On Mar 20, 3:00 pm, Scott Carter scarter28m-goo...@yahoo.com wrote: I'm starting to look at the OAuth process and had a question for the OAuth folks at Twitter. My application BigTweet is invoked via a bookmarklet and displays as an IFRAME on any web page that a Twitter user happens to be browsing.Ideally I would like to be able to complete the entire OAuth process within the IFRAME (for initial login). I believe that Twitter recently added measures to prevent framing of their site to stop phishing attacks. Does this extend to the OAuth approval page? Could an exception be made for the OAuth page when invoked from a registered application presenting a valid Request Token? If so, could this be documented (perhaps in the OAuth Twitter FAQ)? The authorization page at Twitter appears to have a fairly small content section (with Deny/Allow buttons, etc), which could fit into a reasonably sized IFRAME. If you are agreeable to allow IFRAME support, would it be possible to standardize on content dimensions (for IFRAME sizing) and document this as well? Thanks for considering my request. Scotthttp
[twitter-dev] Re: google bookmarklet-like utility for twitter
You can try BigTweet - http://bigtweet.com/
On Feb 22, 9:03 am, v4vijayakumar vijayakumar.subbu...@gmail.com
wrote:
First post.
I am looking for, google bookmarklet like utility for twitter, so
that I can tweet from my browser, without visiting twitter web page.
google bookmarklet is a simple javascript code and this can be added
into browser bookmarks.
javascript:(function(){var
%20a=window,b=document,c=encodeURIComponent,d=a.open(http://www.google.com/bookmarks/mark?op=editoutput=popupbkmk=+c(b.location)+title=+c(b.title),bkmk_popup,left=+((a.screenX||a.screenLeft)+10)+,top=+((a.screenY||a.screenTop)+10)+,height=420px,width=550px,resizable=1,alwaysRaised=1);a.setTimeout(function(){d.focus()},300)})();
Can't view/retrieve full text message with length greater than 140 and = 160 characters?
Hi Alex, Please refer to a related thread at: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/d11a31c7ecf033b/130ed44d6b502e6c?lnk=gstq=160#130ed44d6b502e6c I am trying to send an update via the API that is greater than 140 characters, but = 160. When I try to view the whole message on the Web by clicking on the elipsis ... I do not see the full message. I tried the following two calls: http://twitter.com/statuses/user_timeline.json http://twitter.com/statuses/user_timeline.xml In both cases, I see truncated set to true, and the value of text is the same as what I see on the Web - not the full message. Is it no longer possible to see/retrieve an update where 140 length = 160 ? If this is the case, why does the documentation at http://apiwiki.twitter.com/REST+API+Documentation say Must not be more than 160 characters under the update function? An example with 155 characters is: http://twitter.com/blueskies2/status/1068333279 Almost a foot of snow was predicted for parts of central Michigan, CNN affiliate WNEM-TV in Saginaw reported. Classes were canceled in hundreds of schools. This is a protected update (my developer account) - please feel free to view it for debug as needed. Thanks in advance for a clarification. Scott
