[twitter-dev] Re: Where to enter the pin number for desktop clients
just add the one more input parameter oauth_verifier for pin in accessToken.html (make sure you trim the extra space while pasting the value) It should work fine On Jul 31, 9:59 am, mani wrote: > Hi, > > I got the token secret & aouth_token > throughhttp://oauth.googlecode.com/svn/code/javascript/example/requestToken > > And used the token i got to authorize with the username/password. > > I used following url. Where in i filled like below and put in the > browser. > It asked me > username/passwordhttp://twitter.com/oauth/authorize?oauth_token=&oauth_callback=oob > > for callback i provided oob as told in > thehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-authorize > > It asked me username/password then > Twitter.com provided me a pin number and asked me enter in my > application where i registered. > > But i dont where exactly to enter that pin number ? > > I have to get an access token next ? > > http://apiwiki.twitter.com/Authentication > > I read in the following link. If it is a deskto client flow, then call > back will be like,, a 7 digit pin number will be provided . Enter it > in the application. > # After obtaining approval from the user, a prompt on twitter.com will > display a 7 digit PIN. > # The user is instructed to copy this PIN and return to the > appliction. > # The application will prompt the user to enter the PIN from step 4. > > IF i use browser where i have to enter this pin number ? > Or i have write a full end to end application,? not just like form url > and test in browset get access token ? > How does this flow really works...? desktop client. > Thanks, > Mani
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay wrote: > I understand the reasoning behind OAuth, and think it's a step in the right > direction, but, does Twitter have plans to improve and move to a better Auth > system than OAuth? With Facebook Connect I just have to click once, and if > the user is already logged in and approved my app, they never see the > Facebook login box again. Where as with Twitter there are 3 points of > potential failure every single time the user logs in. It's a Ux nightmare, > IMO. While it does solve a problem, I don't think OAuth is the end or ideal > solution. Are there plans to improve this process? > Jesse > > > On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams wrote: > >> Well said, Duane. >> Thanks, >> Doug >> >> >> On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands > > wrote: >> >>> >>> First, let me state from the start that I am no fan of OAuth, >>> Twitter's implementation of it, or the way that they've behaved with >>> regard to it. Now, with all that being said. >>> >>> If your website expects me to hand over my Twitter password, I'm not >>> using your web site. Just yesterday, another scam site (TwitViewer) >>> managed to steal thousands of accounts, and convince other people to >>> hand over their information because it was posting tweets from the >>> stolen accounts. >>> >>> OAuth is not perfect, but it provides individual users and Twitter >>> with a way to identify bad actors and lock them out of the ecosystem. >>> >>> OAuth works. There are examples out there. There are developers who >>> are willing to help you. >>> >>> Implementing OAuth tells your customers that the security of their >>> account is important to you, and shutting down Basic Auth trains your >>> users to stop giving away their password. If your product has value, >>> and you clearly communicate what that value is, the users will use >>> OAuth. >>> >>> >>> >>> On Jul 29, 9:10 am, Dewald Pretorius wrote: >>> > It would not surprise me at all if using OAuth resulted in fewer >>> > signups. >>> > >>> > Potential technical advantages of OAuth aside, every additional click >>> > that you add in the conversion process adds an addition leakage point >>> > where some users can and will abandon the signup process. >>> >> >> > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Where to enter the pin number for desktop clients
Hi, I got the token secret & aouth_token through http://oauth.googlecode.com/svn/code/javascript/example/requestToken.html And used the token i got to authorize with the username/password. I used following url. Where in i filled like below and put in the browser. It asked me username/password http://twitter.com/oauth/authorize?oauth_token= &oauth_callback=oob for callback i provided oob as told in the http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-authorize It asked me username/password then Twitter.com provided me a pin number and asked me enter in my application where i registered. But i dont where exactly to enter that pin number ? I have to get an access token next ? http://apiwiki.twitter.com/Authentication I read in the following link. If it is a deskto client flow, then call back will be like,, a 7 digit pin number will be provided . Enter it in the application. # After obtaining approval from the user, a prompt on twitter.com will display a 7 digit PIN. # The user is instructed to copy this PIN and return to the appliction. # The application will prompt the user to enter the PIN from step 4. IF i use browser where i have to enter this pin number ? Or i have write a full end to end application,? not just like form url and test in browset get access token ? How does this flow really works...? desktop client. Thanks, Mani
[twitter-dev] Follow up
I like to take this time to personally THANK Twitter Development for the work your doing and fixing in the line of spam follow up and tactical problems, I know there must be alot of hands full of JUNK! ON Twitter, So may Thanks for what you do!
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams wrote: > Well said, Duane. > Thanks, > Doug > > > On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands > wrote: > >> >> First, let me state from the start that I am no fan of OAuth, >> Twitter's implementation of it, or the way that they've behaved with >> regard to it. Now, with all that being said. >> >> If your website expects me to hand over my Twitter password, I'm not >> using your web site. Just yesterday, another scam site (TwitViewer) >> managed to steal thousands of accounts, and convince other people to >> hand over their information because it was posting tweets from the >> stolen accounts. >> >> OAuth is not perfect, but it provides individual users and Twitter >> with a way to identify bad actors and lock them out of the ecosystem. >> >> OAuth works. There are examples out there. There are developers who >> are willing to help you. >> >> Implementing OAuth tells your customers that the security of their >> account is important to you, and shutting down Basic Auth trains your >> users to stop giving away their password. If your product has value, >> and you clearly communicate what that value is, the users will use >> OAuth. >> >> >> >> On Jul 29, 9:10 am, Dewald Pretorius wrote: >> > It would not surprise me at all if using OAuth resulted in fewer >> > signups. >> > >> > Potential technical advantages of OAuth aside, every additional click >> > that you add in the conversion process adds an addition leakage point >> > where some users can and will abandon the signup process. >> > >
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth lets you access the Twitter service without giving your Twitter credentials to anyone but Twitter. Basic Auth requires you to give your Twitter credentials to someone other than Twitter. Therefore, OAuth is more secure than Basic Auth. This is not rocket science. On Jul 30, 7:07 pm, "Bradley S. O'Hearne" wrote: > In that case, OAuth *still* requires production of credentials to a > complete stranger. Because it supposedly redirects to the Twitter web > site for authentication doesn't save you from the either originating > web site, the browser, or the machine itself spoofing the redirect -- > I mean you've already labeled them "a complete stranger", so you have > to allow now for that possibility. Additionally, that login directly > into Twitter also doesn't save you from keyboard logging or phishing > on the machine -- or, and I'm not 100% sure on this one but I think it > is possible, malicious browser plugins. So here we get into the issue > of not just a single trusted / non-trusted app, but whether it is a > trusted box or not. > > Perhaps I'm still ignorant, but unless I've completely missed the > boat, credentials are still being produced -- i mean, at some point > they have to be, otherwise they wouldn't be credentials, something > else would be. I think what I'm really responding to here is the lack > of context given to discussions surrounding OAuth's security -- there > are blanket statements being made about not giving a stranger > passwords, and OAuth somehow solving that. Well, that "stranger" > happens to be the machine you've chosen to trust. Just because OAuth > exists, it doesn't make Twittering or accessing Twitter data from > Facebook on an Internet Cafe computer any safer necessarily. There is > a degree of trust somewhere that is being trusted as a beginning > prerequisite. I do not believe there is a no-trust scenario here. What > I really want to hear stated, or read on a FAQ, is the pre-requisite > security trust, that in that scenario, it necessarily makes OAuth > superior to basic authentication. > > Brad > > On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: > > > > > > > Brad, > > > Encryption on disk and encryption over the wire are not the issues and > > really don't have very much to do with the Basic vs. OAuth decision. > > > The most important issue I see is that Basic Auth requires you to give > > your Twitter credentials to a person you do not know. This is a BAD > > IDEA. > > > Basic Auth is great for prototyping and testing and getting the core > > functionality of your app working, but at some point you should bit > > the bullet and implement OAuth. It's better for your customers > > (security) and it's better for you because your customers can use your > > application with peace of mind. > > > If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's > > silly to expect your users to do so. > > > On Jul 30, 11:40 am, "Bradley S. O'Hearne" > > wrote: > > >> In conclusion, as I've been reading this thread, the thing I keep > >> coming back to is that OAuth vs. Basic Auth seems somewhat a > >> secondary > >> argument -- the real issue is encrypting over the wire (HTTPS) and > >> encryption on disk, and whether those can be cracked (or are being > >> used as they should). From a developer standpoint, given that the > >> cracking of encryption seems outside the scope of concerns with the > >> Twitter API, what is analog is which one serves the user better -- > >> and > >> I think it is clear that the Basic Auth case has fewer steps and > >> quicker to the result. > > >> Please correct my misperceptions if I'm wrong, as I'd love to hear > >> what details I've overlooked. > > >> Regards, > > >> Brad > > >> On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: > > >>> On Jul 28, 3:27 pm, chinaski007 wrote: > > I suppose this is not so weird. Users are accustomed to giving > user/ > pass information even to "foreign" apps. > > >>> Agree. Anyway, if user just setups desktop app to his computer, he > >>> already gives it much more than just login/password to some service. > >>> And then there is 1000 and 1 way how app can then get all needed > >>> info > >>> passing over user. > > >>> -- > >>> Dmitriy V'jukov
[twitter-dev] Trending Topic hashtag breaking
The query for the trending topic is "#HootSuite 2" but when you click on it, it says that no results were found. However if you just search #HootSuite 2 (no quotes) it returns all the appropriate results (mostly with the term HootSuite 2.0) . It appears that there is some confusion between the term stored for the trending topic and the results found with the search query.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
You can lead a horse to water ... On Thu, Jul 30, 2009 at 7:07 PM, Bradley S. O'Hearne wrote: > > Duane, > > I understand the concern. But I think the conversation is moving > closer to the actual issue. Your example of turning Twitter > credentials to a stranger basically makes the application (or > computer) that the user has already willfully chosen to use "a > complete stranger". I would debate that is necessarily the case, but > let's for the moment assume it is the case, and see the problem with > that assumption. > > In that case, OAuth *still* requires production of credentials to a > complete stranger. Because it supposedly redirects to the Twitter web > site for authentication doesn't save you from the either originating > web site, the browser, or the machine itself spoofing the redirect -- > I mean you've already labeled them "a complete stranger", so you have > to allow now for that possibility. Additionally, that login directly > into Twitter also doesn't save you from keyboard logging or phishing > on the machine -- or, and I'm not 100% sure on this one but I think it > is possible, malicious browser plugins. So here we get into the issue > of not just a single trusted / non-trusted app, but whether it is a > trusted box or not. > > Perhaps I'm still ignorant, but unless I've completely missed the > boat, credentials are still being produced -- i mean, at some point > they have to be, otherwise they wouldn't be credentials, something > else would be. I think what I'm really responding to here is the lack > of context given to discussions surrounding OAuth's security -- there > are blanket statements being made about not giving a stranger > passwords, and OAuth somehow solving that. Well, that "stranger" > happens to be the machine you've chosen to trust. Just because OAuth > exists, it doesn't make Twittering or accessing Twitter data from > Facebook on an Internet Cafe computer any safer necessarily. There is > a degree of trust somewhere that is being trusted as a beginning > prerequisite. I do not believe there is a no-trust scenario here. What > I really want to hear stated, or read on a FAQ, is the pre-requisite > security trust, that in that scenario, it necessarily makes OAuth > superior to basic authentication. > > Brad > > On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: > > > > > Brad, > > > > Encryption on disk and encryption over the wire are not the issues and > > really don't have very much to do with the Basic vs. OAuth decision. > > > > The most important issue I see is that Basic Auth requires you to give > > your Twitter credentials to a person you do not know. This is a BAD > > IDEA. > > > > Basic Auth is great for prototyping and testing and getting the core > > functionality of your app working, but at some point you should bit > > the bullet and implement OAuth. It's better for your customers > > (security) and it's better for you because your customers can use your > > application with peace of mind. > > > > If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's > > silly to expect your users to do so. > > > > On Jul 30, 11:40 am, "Bradley S. O'Hearne" > > wrote: > > > >> In conclusion, as I've been reading this thread, the thing I keep > >> coming back to is that OAuth vs. Basic Auth seems somewhat a > >> secondary > >> argument -- the real issue is encrypting over the wire (HTTPS) and > >> encryption on disk, and whether those can be cracked (or are being > >> used as they should). From a developer standpoint, given that the > >> cracking of encryption seems outside the scope of concerns with the > >> Twitter API, what is analog is which one serves the user better -- > >> and > >> I think it is clear that the Basic Auth case has fewer steps and > >> quicker to the result. > >> > >> Please correct my misperceptions if I'm wrong, as I'd love to hear > >> what details I've overlooked. > >> > >> Regards, > >> > >> Brad > >> > >> On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: > >> > >> > >> > >> > >> > >>> On Jul 28, 3:27 pm, chinaski007 wrote: > >> > I suppose this is not so weird. Users are accustomed to giving > user/ > pass information even to "foreign" apps. > >> > >>> Agree. Anyway, if user just setups desktop app to his computer, he > >>> already gives it much more than just login/password to some service. > >>> And then there is 1000 and 1 way how app can then get all needed > >>> info > >>> passing over user. > >> > >>> -- > >>> Dmitriy V'jukov > >
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Duane, I understand the concern. But I think the conversation is moving closer to the actual issue. Your example of turning Twitter credentials to a stranger basically makes the application (or computer) that the user has already willfully chosen to use "a complete stranger". I would debate that is necessarily the case, but let's for the moment assume it is the case, and see the problem with that assumption. In that case, OAuth *still* requires production of credentials to a complete stranger. Because it supposedly redirects to the Twitter web site for authentication doesn't save you from the either originating web site, the browser, or the machine itself spoofing the redirect -- I mean you've already labeled them "a complete stranger", so you have to allow now for that possibility. Additionally, that login directly into Twitter also doesn't save you from keyboard logging or phishing on the machine -- or, and I'm not 100% sure on this one but I think it is possible, malicious browser plugins. So here we get into the issue of not just a single trusted / non-trusted app, but whether it is a trusted box or not. Perhaps I'm still ignorant, but unless I've completely missed the boat, credentials are still being produced -- i mean, at some point they have to be, otherwise they wouldn't be credentials, something else would be. I think what I'm really responding to here is the lack of context given to discussions surrounding OAuth's security -- there are blanket statements being made about not giving a stranger passwords, and OAuth somehow solving that. Well, that "stranger" happens to be the machine you've chosen to trust. Just because OAuth exists, it doesn't make Twittering or accessing Twitter data from Facebook on an Internet Cafe computer any safer necessarily. There is a degree of trust somewhere that is being trusted as a beginning prerequisite. I do not believe there is a no-trust scenario here. What I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. Brad On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: > > Brad, > > Encryption on disk and encryption over the wire are not the issues and > really don't have very much to do with the Basic vs. OAuth decision. > > The most important issue I see is that Basic Auth requires you to give > your Twitter credentials to a person you do not know. This is a BAD > IDEA. > > Basic Auth is great for prototyping and testing and getting the core > functionality of your app working, but at some point you should bit > the bullet and implement OAuth. It's better for your customers > (security) and it's better for you because your customers can use your > application with peace of mind. > > If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's > silly to expect your users to do so. > > On Jul 30, 11:40 am, "Bradley S. O'Hearne" > wrote: > >> In conclusion, as I've been reading this thread, the thing I keep >> coming back to is that OAuth vs. Basic Auth seems somewhat a >> secondary >> argument -- the real issue is encrypting over the wire (HTTPS) and >> encryption on disk, and whether those can be cracked (or are being >> used as they should). From a developer standpoint, given that the >> cracking of encryption seems outside the scope of concerns with the >> Twitter API, what is analog is which one serves the user better -- >> and >> I think it is clear that the Basic Auth case has fewer steps and >> quicker to the result. >> >> Please correct my misperceptions if I'm wrong, as I'd love to hear >> what details I've overlooked. >> >> Regards, >> >> Brad >> >> On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: >> >> >> >> >> >>> On Jul 28, 3:27 pm, chinaski007 wrote: >> I suppose this is not so weird. Users are accustomed to giving user/ pass information even to "foreign" apps. >> >>> Agree. Anyway, if user just setups desktop app to his computer, he >>> already gives it much more than just login/password to some service. >>> And then there is 1000 and 1 way how app can then get all needed >>> info >>> passing over user. >> >>> -- >>> Dmitriy V'jukov
[twitter-dev] 401 Unauthorized When Getting an Access Token
I am using ASP .NET (VB) to try and authenticate using oAuth. I have been able to get a request token and direct a user to Twitter's authentication page. Twitter then redirects back to my app. At that point I attempt to get an access token, but I continue to receive 401 "unauthorized" errors. I have made sure that I am getting a new signature, using both the token and token secret when generating the signature, and that my url parameters are in alphabetical order, but I continue to get 401 errors. Has anyone experienced this, and if so, could you point me in the right direction toward diagnosing this issue? -Matt
[twitter-dev] Re: Fetch multiple statuses by ID
not possible. you have to store the tweets on your end and build your own query. On Wed, Jul 29, 2009 at 10:37 AM, Michael Mahemoff wrote: > > Greetings. Is there any way to fetch multiple statuses in a single > request, by passing in all the status IDs? As in: > > http://twitter.com/statuses/show/123,456,789.json returning tweets > 123, 456, 789. > > Use case: I run http://listoftweets.com, where users can build up a > list of tweets from search results. There's no persistence right now, > but I would like to make a new feature, letting people save a list of > tweets on my server. It would be redundant for my site to capture the > full details of all the tweets in the list, when that information is > already in Twitter; I'd like to just save a list of IDs and make a > single call on Twitter to pull them out. As it stands, AFAICT, I'd > have to make a unique call for every tweet in the list, which is > obviously not practical. >
[twitter-dev] Help signing OAuth requests
For those who might be struggling to ensure their OAuth signatures are being generated correctly, this guide provides more hand holding with the process than the specification. It includes custom forms where you can fill out all the details of your request and see what the signature and its related data *should* be. http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
After all this discussion, I'm a bit nervous that I may missed something that needs to be fixed. Does anyone know of a good testcase that will trigger the failures in the OAuthConsumer libs? I've checked POST, seems to work as expected. Tested odd encodings (like spaces and other things that need urlencoding), those seem OK too. What am I missing? Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 30, 2009, at 2:27 PM, jonat...@scribblelive wrote: I may be the only one to be this stupid, but when I looked at my POST request functions, I was appending some parameters like "Source", etc. that were common to all requests. But since they weren't there when the signature was generated, we were getting 401 errors as of 7/27. Removing those fixed us right up. --Jonathan On Jul 28, 12:46 am, Duane Roelands wrote: From my experimenting, it appears that posting a tweet is successful if the text contains no spaces. Once you have a space in the tweet, it fails. Researching... On Jul 28, 12:29 am, winrich wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelands wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that "a security change was pushed today" would be nice, though. -Chad
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I may be the only one to be this stupid, but when I looked at my POST request functions, I was appending some parameters like "Source", etc. that were common to all requests. But since they weren't there when the signature was generated, we were getting 401 errors as of 7/27. Removing those fixed us right up. --Jonathan On Jul 28, 12:46 am, Duane Roelands wrote: > From my experimenting, it appears that posting a tweet is successful > if the text contains no spaces. Once you have a space in the tweet, > it fails. Researching... > > On Jul 28, 12:29 am, winrich wrote: > > > ok guys. > > > so my calls were failing on the verify_credentials call and not on the > > update or timeline calls. the only difference i saw was the the > > verify_credential call wasn't secured. i changed it to https and it > > worked. ??? lol > > > On Jul 27, 9:19 pm, Chad Etzel wrote: > > > > On Mon, Jul 27, 2009 at 11:55 PM, Duane > > > > Roelands wrote: > > > > RTFM is not a helpful answer, especially when many developers are > > > > relying on libraries that they did not write. > > > > That's a risk you run when using code you didn't write. > > > > I'm not saying that this situation doesn't suck for those affected. > > > I'm sure that it does. But, for a technology so new as OAuth, the > > > libraries may not be mature yet. > > > > Officially, Twitter OAuth is still in Public Beta and has never been > > > officially recommended to integrate into production code. That being > > > said, there could still be a problem on Twitter's end with their > > > signature verification mechanism and the libraries could all be valid. > > > I don't have a way of knowing. > > > > I do agree that at least a note that "a security change was pushed > > > today" would be nice, though. > > > > -Chad
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I don't know if this will help at all, but I had the same problem...after hours spent on this stupid error, I realized that some of my request URLs were using http, and some https. After changing all the request URLs to https, everything's working perfectly (I'm using exactly the same client library). It does make all kinds of sense. Regular http requests worked fine before, though. It's probably been mentioned before. If so, I missed it, sorry. :) On Jul 30, 12:03 pm, Andreu wrote: > I read this discussion carefully and I cannot extract a conclusion... > > The question is why a set of API methods are working and others aren't > working properly, returning a 'Incorrect signature' error. > > Methods working now: > - posting a tweet (statuses/update). Works fine > - extract user timeline (statuses/user_timeline). Works fine either > the request is made by the authenticated user (user requesting his own > timeline) or requesting a 3rd user timeline > - verify credentials (account/verify_credentials). Works fine. > > Methods not working: > - delete a tweet (statuses/destroy). > - destroy a relationship (friendships/destroy) > - create a relationship (friendships/create) > - extract friends timeline (statuses/friends_timeline) > > All methods are relying over the same base python method, building the > same requests changing the API urls and/or parameters... The library I > am using ishttp://oauth.googlecode.com/svn/code/python/oauth/oauth.py > > I think if server signature verification have been modified, and now > is running 'properly', all my methods should fail, especially the > methods that authentication is required... but the problem is ones are > working and others not working.
[twitter-dev] Re: Pending follow requests for protected users
Ahh - next time I'll be sure to look at the roadmap first. Thanks, Abraham. On Jul 30, 3:49 pm, Abraham Williams <4bra...@gmail.com> wrote: > Planned:http://code.google.com/p/twitter-api/issues/detail?id=8 > > On Thu, Jul 30, 2009 at 13:39, Bill Kocik wrote: > > > If a user is protected, any attempt to follow them creates a request > > they must approve. Is there any API for retrieving these pending > > requests, and approving or denying them? > > > I don't see anything in the docs, so I'm guessing not, but thought it > > couldn't hurt to ask. > > > Thanks... > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: My username capitalization appears wrong in twitter search
This is a known issue: http://code.google.com/p/twitter-api/issues/detail?id=626 On Thu, Jul 30, 2009 at 13:47, Jeff L wrote: > > Hello, I'm almost 100% sure that this isn't the right place to post > this, but: > > a) I've filed two twitter help tickets with no helpful response > whatsoever > b) The response to my latest ticket gave me a link to the Twitter API > Wiki for some reason so here I am > c) I'm hoping someone here, possibly a dev, will help me solve this > problem that's existed for months now > > Issue: My username capitalization appears wrong in twitter search. > > Incorrect: JeffLIu > Correct: jeffliu > > Link: http://twitter.com/#search?q=jeffliu > > Is there any way I can correct this? > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
@noradio - thanks for the notification, belated though it was. FWIW I am using the OAuthConsumer Objective-C library - http://code.google.com/p/oauthconsumer/ Its already behind with the verifier change, but there are posts the FAQ on how to get it working with that and now this change. The fix this time involved only sending the "oauth_verifier=" part when a non-empty verifier is available. Not sure why thats a fix - or if its a complete fix... but I can post from my app again :) Regards, Chris 2009/7/28 Doug Williams > If you are using a client library, please specify the library and version. > There is a chance that you are all running into the same library-based > incompatibility and could work together (or with the maintainer) to > determine the fix.
[twitter-dev] Re: Twitter4J 2.0.9 released - introduces tons of bugs, and lots of new features including Android support
Thanks a lot Yusuke, Did you do any major changes to Oauth aoart from fixing TFJ-187? I will get working with this for twaller.com /Amitab On Jul 30, 5:36 am, Yusuke Yamamoto wrote: > Versoin 2.0.9 is not meant to introduce tons of bugs, it actually > *fixes* tons of bugs of course. > -- > Yusuke Yamamoto > yus...@mac.com > > this email is: [x] bloggable/tweetable [ ] ask first [ ] private > follow me on :http://twitter.com/yusukeyamamoto > subscribe me at :http://yusuke.homeip.net/blog/ > > On 2009/07/30, at 2:16, Yusuke Yamamoto wrote: > > > > > Hi all, > > > Twitter4J 2.0.9 is available for download. > >http://yusuke.homeip.net/twitter4j/en/index.html#download > > It is(or will be) also available at the Maven central repository. > >http://repo1.maven.org/maven2/net/homeip/yusuke/twitter4j/ > > Snapshot builds can be found at: > >http://yusuke.homeip.net/maven2/net/homeip/yusuke/twitter4j/ > > > Release Notes - Twitter4J - Version 2.0.9 - HTML format > > Bug > > [TFJ-167] - push style streaming thread quits with IOException > > [TFJ-173] - " is mapped to \\u0022 > > [TFJ-175] - Streaming API now requires comma separated follow > > parameter > > [TFJ-181] - ExceptionInInitializationError on Android platforms > > [TFJ-187] - SerializationException with twitter4j.http.OAuth > > [TFJ-189] - TwitterException with streaming API : > > twitter4j.TwitterException: JSONObject["id"] not found with > > streaming api > > Improvement > > [TFJ-174] - inconsistent method names in User Methods > > [TFJ-177] - the scope of the junit dependencies in the pom should be > > set to test > > [TFJ-178] - getPublicTimeline(int sinceID) should take long sinceId > > [TFJ-179] - scope of junit should be "test", not "compile" > > [TFJ-180] -http://twitter.com/statuses/friends_timeline/ > > .xml is not supported anymore > > [TFJ-182] - ExceptionInInitializerError with Java applets > > [TFJ-183] - method name refactor: RateLimitStatus.getDateTime() -> > > RateLimitStatus.getResetTime() > > New Feature > > [TFJ-163] - introduce twitter4j.properties that overrides default > > properties > > [TFJ-170] - dynamic callback support > > [TFJ-176] - Streaming API : support track method > > Task > > [TFJ-184] - refactor: some fields in HttpClient can be static > > [TFJ-190] - slf4j, and rome are not required libraries, scope in > > pom.xml should be "provided" instead of "compile" > > Cheers, > > -- > > Yusuke Yamamoto > > yus...@mac.com > > > this email is: [x] bloggable/tweetable [ ] ask first [ ] private > > follow me on :http://twitter.com/yusukeyamamoto > > subscribe me at :http://yusuke.homeip.net/blog/
[twitter-dev] My username capitalization appears wrong in twitter search
Hello, I'm almost 100% sure that this isn't the right place to post this, but: a) I've filed two twitter help tickets with no helpful response whatsoever b) The response to my latest ticket gave me a link to the Twitter API Wiki for some reason so here I am c) I'm hoping someone here, possibly a dev, will help me solve this problem that's existed for months now Issue: My username capitalization appears wrong in twitter search. Incorrect: JeffLIu Correct: jeffliu Link: http://twitter.com/#search?q=jeffliu Is there any way I can correct this?
[twitter-dev] Re: Twitter + OAuth for iPhone
Sorry, I should have been more careful when prepending my read me content. I've updated the read me file on GitHub, but basically: Use the project in the Demo folder. You'll need to replace the strings in Demo/Src/OAuthTwitterDemoViewController.m with your own consumer key and consumer secret (visit http://twitter.com/oauth_clients/new to obtain these). HTH, B On Jul 30, 3:42 am, Marneo wrote: > Ben, > > It says in the read me file that: > Use the key and secret info provided there to modify the constants at > the top of YHOAuthTwitterEngine.m > You should also set up your callback url at the top of the YHTwitter.m > > But I cant find these files. Where can I find these files and edit > them for my info. Thanks! > > On Jul 30, 1:50 am, Ben Gottlieb wrote: > > > > > Okay, sendUpdate is now working with spaces again. > > > On Jul 29, 10:41 am, Ben Gottlieb wrote: > > > > Update: it's not working if you have %-escaped characters in your > > > update status string. It appears that there may be some double- > > > escaping going on, and that may be confusing things. Not sure if this > > > is my code or something else (this was working over the weekend, but > > > something else may have changed before I committed to GitHub.). In > > > progress. > > > > B > > > > On Jul 29, 8:31 am, Ben Gottlieb wrote: > > > > > I just re-tested the code this morning, and it still works. > > > > > On Jul 29, 6:03 am, chloros wrote: > > > > > > Does this currently work? I'm using OAuthConsumer as well and my app > > > > > stopped working after the last update. > > > > > > On Jul 28, 2:32 pm, Ben Gottlieb wrote: > > > > > > > If anyone is interested, I've implemented Twitter OAuth on iPhone > > > > > > (which includes an iPhone version of the OAuth static lib). It's on > > > > > > GitHub:http://github.com/bengottlieb/Twitter-OAuth-iPhone/tree/master
[twitter-dev] Re: Pending follow requests for protected users
Planned: http://code.google.com/p/twitter-api/issues/detail?id=8 On Thu, Jul 30, 2009 at 13:39, Bill Kocik wrote: > > If a user is protected, any attempt to follow them creates a request > they must approve. Is there any API for retrieving these pending > requests, and approving or denying them? > > I don't see anything in the docs, so I'm guessing not, but thought it > couldn't hurt to ask. > > Thanks... -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Brad, Encryption on disk and encryption over the wire are not the issues and really don't have very much to do with the Basic vs. OAuth decision. The most important issue I see is that Basic Auth requires you to give your Twitter credentials to a person you do not know. This is a BAD IDEA. Basic Auth is great for prototyping and testing and getting the core functionality of your app working, but at some point you should bit the bullet and implement OAuth. It's better for your customers (security) and it's better for you because your customers can use your application with peace of mind. If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's silly to expect your users to do so. On Jul 30, 11:40 am, "Bradley S. O'Hearne" wrote: > In conclusion, as I've been reading this thread, the thing I keep > coming back to is that OAuth vs. Basic Auth seems somewhat a secondary > argument -- the real issue is encrypting over the wire (HTTPS) and > encryption on disk, and whether those can be cracked (or are being > used as they should). From a developer standpoint, given that the > cracking of encryption seems outside the scope of concerns with the > Twitter API, what is analog is which one serves the user better -- and > I think it is clear that the Basic Auth case has fewer steps and > quicker to the result. > > Please correct my misperceptions if I'm wrong, as I'd love to hear > what details I've overlooked. > > Regards, > > Brad > > On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: > > > > > > > On Jul 28, 3:27 pm, chinaski007 wrote: > > >> I suppose this is not so weird. Users are accustomed to giving user/ > >> pass information even to "foreign" apps. > > > Agree. Anyway, if user just setups desktop app to his computer, he > > already gives it much more than just login/password to some service. > > And then there is 1000 and 1 way how app can then get all needed info > > passing over user. > > > -- > > Dmitriy V'jukov
[twitter-dev] Re: Preventing Twitter from interpreting "@" characters
OH. missed the url part. Could you URL-escape it? That is, instead of using @, use %40? On Thu, Jul 30, 2009 at 12:27, Howard Siegel wrote: > Which will destroy the URL. ;-O > > - h > > > On Thu, Jul 30, 2009 at 10:50, JDG wrote: > >> put a space after the @ sign? >> >> >> On Wed, Jul 29, 2009 at 22:11, Bradley S. O'Hearne < >> brad.ohea...@gmail.com> wrote: >> >>> >>> Hello all, >>> >>> I am trying to post a URL to a Twitter status that has a "@" character >>> in it. The problem is probably obvious -- anyone know how to prevent >>> Twitter from interpreting the "@" as a username? >>> >>> Thanks, >>> >>> Brad >>> >> >> >> >> -- >> Internets. Serious business. >> > > -- Internets. Serious business.
[twitter-dev] Re: Application statistics
Oh my goodness! Thank you, thank you, thank you! I didn't know you can do that! Not that is serves my purpose for the question I asked but it's a gem - I already have a fantastic idea for a killer app :) On Jul 29, 9:34 pm, Abraham Williams <4bra...@gmail.com> wrote: > You can also use the Spritzer alpha for a sampling of public statuses. > > http://apiwiki.twitter.com/Streaming-API-Documentation#spritzer > > > > On Wed, Jul 29, 2009 at 23:01, droidin.net wrote: > > > Oh yes - and if you do something like "source:droidin the" it not > > surprisingly kills the search app "We're sorry, but something went > > wrong." > > > On Jul 29, 3:16 pm, Abraham Williams <4bra...@gmail.com> wrote: > > > You can use source:appname to search twitter: > >http://search.twitter.com/search?q=source%3Aapi+test > > > > Of course if your application is posting your updates they most accurate > > > method would be to collect the statistics as you interact with the api. > > > > Abraham > > > > 2009/7/29 droidin.net > > > > > Is this monitored by the Twitter team? If you guys have no solution > > > > for this - just tell, I'll code something > > > > > On Jul 28, 10:22 am, "droidin.net" wrote: > > > > > Is there a way of tracking who and how is using your app? Simple > > > > > search based on app name (like "from DroidIn") does not yield any > > > > > results > > > > -- > > > Abraham Williams | Community Evangelist |http://web608.org > > > Hacker |http://abrah.am|http://twitter.com/abraham > > > Project |http://fireeagle.labs.poseurtech.com > > > This email is: [ ] blogable [x] ask first [ ] private. > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Pending follow requests for protected users
If a user is protected, any attempt to follow them creates a request they must approve. Is there any API for retrieving these pending requests, and approving or denying them? I don't see anything in the docs, so I'm guessing not, but thought it couldn't hurt to ask. Thanks...
[twitter-dev] Re: Preventing Twitter from interpreting "@" characters
Which will destroy the URL. ;-O - h On Thu, Jul 30, 2009 at 10:50, JDG wrote: > put a space after the @ sign? > > > On Wed, Jul 29, 2009 at 22:11, Bradley S. O'Hearne > wrote: > >> >> Hello all, >> >> I am trying to post a URL to a Twitter status that has a "@" character >> in it. The problem is probably obvious -- anyone know how to prevent >> Twitter from interpreting the "@" as a username? >> >> Thanks, >> >> Brad >> > > > > -- > Internets. Serious business. >
[twitter-dev] Re: OAuth URLEncode for VB.NET Libraries
Here's TwitterOAuth.vb, the OAuth class I'm using for my Twitter client. http://dpaste.com/73411/ This is a VB.NET port of Shannon Whitley's C# class, with a few tweaks and extensions. My client's still a 0.5 alpha, so it's entirely possible that there are still holes in this. If you find any, I'd be grateful to know so I can fix them. On Jul 30, 12:53 pm, Ney Garcia wrote: > Hi guys, > I have gone into the same problem : my app uses OAuth to post tweets > and went ok over the weekend but on Monday, Twitter started refusing > OAuth posts. My app then tries to post using basic method, and it > works. > I also implemented OAuth using Shannon Whitley's example, which I > transformed in a Web Service. > I saw Duane's VB code but I havent noticed what has changed from > original UrlEncode method. > Would you give me any help ? > > Thanks in advance. > > Ney. > > On 28 jul, 15:13, Duane Roelands wrote: > > > > > My application appears to be back in the game, after some corrections > > to my url encoding. I've posted the code here (http://dpaste.com/hold/ > > 72568/) for the benefit of other VB.NET developers. > > > This is a VB.NET port of the URLEncode method found in the Twitter/ > > OAuth class from Shannon Whitley and Eran Sandler. They rock. > > > Hopefully, this gets you guys back in the game as well.
[twitter-dev] Re: Preventing Twitter from interpreting "@" characters
put a space after the @ sign? On Wed, Jul 29, 2009 at 22:11, Bradley S. O'Hearne wrote: > > Hello all, > > I am trying to post a URL to a Twitter status that has a "@" character > in it. The problem is probably obvious -- anyone know how to prevent > Twitter from interpreting the "@" as a username? > > Thanks, > > Brad > -- Internets. Serious business.
[twitter-dev] Re: Search API: since_id is now unreliable
Brooks,As I stated previously, it is a large problem (much deeper than the API) that will take some time to fix. The search team is growing aggressively, and the new engineers are quickly getting up to speed. One of their tasks is to make progress on the bottleneck causing this problems. That said, there is no ETA on a fix. Thanks, Doug On Thu, Jul 30, 2009 at 7:12 AM, Brooks Bennett wrote: > > Doug, > > Is there any status update on this issue? Users are really starting to > get frustrated with results and wondering what the status is on things > getting back to being consistent... > > Thanks! > > Brooks > > > > > On Jul 21, 3:45 pm, Doug Williams wrote: > > Chad,Your assessment is spot on. > > > > At the heart of search there are a number of data stores that accept > queries > > (reads) while at the same time perform writes from an indexer. Heavy load > -- > > large numbers of queries, large number of writes or both, or both -- can > > cause the write replication between the indexer and various data stores > to > > grow inconsistent when a particular data store is blocked on a read. > > > > Unfortunately there is no easy fix for this problem at the moment. The > > search team has grown considerably in the last couple of weeks so as they > > get up to speed, the feature set and stability of search should continue > to > > improve. > > > > Thanks, > > Doug > > > > > > > > On Tue, Jul 21, 2009 at 11:57 AM, Chad Etzel > wrote: > > > > > Hi API Team, > > > > > A few of us have been discussing off list a funky behavior we have > > > been noticing and now users are starting to notice. > > > > > There is a problem for sites/apps like TweetGrid and TweetChat which > > > auto-refresh tweets based on the Search API using the since_id. People > > > are noticing that these sites are "missing tweets" when compared to > > > the search.twitter.com results page for the same query. > > > > > We believe what is happening is that the search servers are not > > > indexing tweets in a serial manner, and so a tweet with a higher id > > > may sneak into a search server and be indexed first before a tweet > > > with a lower id. This means that when the since_id is sent back from > > > the query (or derived from the first result in the results array), > > > using that since_id to refresh the query will miss lower id tweets > > > when they finally do get indexed. So the illusion of "missing tweets" > > > is created. You can run TweetGrid and TweetChat in separate tabs using > > > the same query and see that sometimes the results don't match up > > > because of this. > > > > > I'll try to give an example to be clear. > > > > > Let's say for the sake of simplicity that I'm searching for "twitter" > > > and that every 10th tweet in the public timeline matches. So, all > > > tweets ending in 0 match my query. > > > > > Search server 1 may index: > > > > > 20 > > > 30 > > > 40 > > > 60 > > > 70 > > > > > (notice missing 50) > > > > > At the same time, Search server 2 may index: > > > > > 20 > > > 30 > > > 40 > > > 50 > > > > > (notice hasn't indexed 60 or 70 yet) > > > > > I send a query and get a response from Server 1 and get a since_id of > > > 70. On my next request I use that since_id=70 and I'll never see > > > tweet 50. Thus the "missing tweets". > > > > > This is quite annoying, especially now that users are noticing and > > > complaining to us (the app devs) that are apps are broken. > > > > > I cannot think of a good work around for this that would be simple > > > enough to implement and be worth the effort. > > > > > Is this behavior something anyone else can confirm? Are tweets > > > supposed to be indexed/replicated serially by the search servers? > > > > > -Chad >
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Thu, Jul 30, 2009 at 11:40 AM, Bradley S. O'Hearne < brad.ohea...@gmail.com> wrote: > > *snip* A ... have you missed the last 12 months of Twitterverse drama? You can't trust random third party apps who demand your credentials. How do we know what they'll do with it? There was a breach just this week, wasn't there? The concerns of passing and storing passwords over-wire and on-disk are, by and far, secondary. Yes, "we" may have the best of intentions, but I don't know you from Joe Six Pack or Johnny Spammer. Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private
[twitter-dev] Re: Where did Advanced Search go?
You can access advanced search here: http://search.twitter.com/advanced Thanks, Doug On Thu, Jul 30, 2009 at 10:01 AM, Vincent Nguyen wrote: > Yes, me too! Dunno where it went?? > > 2009/7/30 Joseph > >> >> From twitter.com. I'm pretty sure it was there a couple of days ago. >> Am I not caffeine'ated enough, or is the feature really gone? > > >
[twitter-dev] Re: Twitter + OAuth for iPhone
Ben, It says in the read me file that: Use the key and secret info provided there to modify the constants at the top of YHOAuthTwitterEngine.m You should also set up your callback url at the top of the YHTwitter.m But I cant find these files. Where can I find these files and edit them for my info. Thanks! On Jul 30, 1:50 am, Ben Gottlieb wrote: > Okay, sendUpdate is now working with spaces again. > > On Jul 29, 10:41 am, Ben Gottlieb wrote: > > > Update: it's not working if you have %-escaped characters in your > > update status string. It appears that there may be some double- > > escaping going on, and that may be confusing things. Not sure if this > > is my code or something else (this was working over the weekend, but > > something else may have changed before I committed to GitHub.). In > > progress. > > > B > > > On Jul 29, 8:31 am, Ben Gottlieb wrote: > > > > I just re-tested the code this morning, and it still works. > > > > On Jul 29, 6:03 am, chloros wrote: > > > > > Does this currently work? I'm using OAuthConsumer as well and my app > > > > stopped working after the last update. > > > > > On Jul 28, 2:32 pm, Ben Gottlieb wrote: > > > > > > If anyone is interested, I've implemented Twitter OAuth on iPhone > > > > > (which includes an iPhone version of the OAuth static lib). It's on > > > > > GitHub:http://github.com/bengottlieb/Twitter-OAuth-iPhone/tree/master
[twitter-dev] Re: Twitter + OAuth for iPhone
One more I also cannot see this location OAuth_ObjC_Test_App/ Example/ . Thanks! On Jul 30, 1:50 am, Ben Gottlieb wrote: > Okay, sendUpdate is now working with spaces again. > > On Jul 29, 10:41 am, Ben Gottlieb wrote: > > > Update: it's not working if you have %-escaped characters in your > > update status string. It appears that there may be some double- > > escaping going on, and that may be confusing things. Not sure if this > > is my code or something else (this was working over the weekend, but > > something else may have changed before I committed to GitHub.). In > > progress. > > > B > > > On Jul 29, 8:31 am, Ben Gottlieb wrote: > > > > I just re-tested the code this morning, and it still works. > > > > On Jul 29, 6:03 am, chloros wrote: > > > > > Does this currently work? I'm using OAuthConsumer as well and my app > > > > stopped working after the last update. > > > > > On Jul 28, 2:32 pm, Ben Gottlieb wrote: > > > > > > If anyone is interested, I've implemented Twitter OAuth on iPhone > > > > > (which includes an iPhone version of the OAuth static lib). It's on > > > > > GitHub:http://github.com/bengottlieb/Twitter-OAuth-iPhone/tree/master
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I read this discussion carefully and I cannot extract a conclusion... The question is why a set of API methods are working and others aren't working properly, returning a 'Incorrect signature' error. Methods working now: - posting a tweet (statuses/update). Works fine - extract user timeline (statuses/user_timeline). Works fine either the request is made by the authenticated user (user requesting his own timeline) or requesting a 3rd user timeline - verify credentials (account/verify_credentials). Works fine. Methods not working: - delete a tweet (statuses/destroy). - destroy a relationship (friendships/destroy) - create a relationship (friendships/create) - extract friends timeline (statuses/friends_timeline) All methods are relying over the same base python method, building the same requests changing the API urls and/or parameters... The library I am using is http://oauth.googlecode.com/svn/code/python/oauth/oauth.py I think if server signature verification have been modified, and now is running 'properly', all my methods should fail, especially the methods that authentication is required... but the problem is ones are working and others not working.
[twitter-dev] Preventing Twitter from interpreting "@" characters
Hello all, I am trying to post a URL to a Twitter status that has a "@" character in it. The problem is probably obvious -- anyone know how to prevent Twitter from interpreting the "@" as a username? Thanks, Brad
[twitter-dev] Re: Where did Advanced Search go?
Yes, me too! Dunno where it went?? 2009/7/30 Joseph > > From twitter.com. I'm pretty sure it was there a couple of days ago. > Am I not caffeine'ated enough, or is the feature really gone?
[twitter-dev] Re: OAuth URLEncode for VB.NET Libraries
Hi guys, I have gone into the same problem : my app uses OAuth to post tweets and went ok over the weekend but on Monday, Twitter started refusing OAuth posts. My app then tries to post using basic method, and it works. I also implemented OAuth using Shannon Whitley's example, which I transformed in a Web Service. I saw Duane's VB code but I havent noticed what has changed from original UrlEncode method. Would you give me any help ? Thanks in advance. Ney. On 28 jul, 15:13, Duane Roelands wrote: > My application appears to be back in the game, after some corrections > to my url encoding. I've posted the code here (http://dpaste.com/hold/ > 72568/) for the benefit of other VB.NET developers. > > This is a VB.NET port of the URLEncode method found in the Twitter/ > OAuth class from Shannon Whitley and Eran Sandler. They rock. > > Hopefully, this gets you guys back in the game as well.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
All, Just a question along the same lines as Dmitriy's, and forwarding no opinion one way or the other -- but I'm curious, as security discussions often end up being debates about one particular facet of a security scheme while not considering the big picture. What is the breach that OAuth is primarily concerned with here? Granted that in principle one doesn't want to be throwing passwords around, but I see two concerns: 1. Passwords being intercepted as sent across the wire. Comment: If credentials have to be passed over the wire to authenticate a session, doesn't HTTPS really alleviate this concern? In order to breach HTTPS you'd have to either crack the encryption, or spoof the Twitter endpoint and support it by somehow spoofing the certificate authority chain. And if someone could do this, then OAuth is no safeguard, because they could do the same with whatever app or session token is the key to the city. 2. Passwords being stored locally. Comment: The application integrating with Twitter is already effectively "trusted", so the concern should not be with the app itself. The concern here would be other apps or people being able to grab passwords off of disk where stored. Again, I think this goes back to encryption. If all credentials are encrypted locally, then again, the concern becomes the breaking of encryption, and if that is done, then again whatever app or session token represents the key to the city can be acquired to use in OAuth too, if I'm not mistaken. Now admittedly, I haven't gone through OAuth with a fine-toothed comb, but I have read the docs and examined the process. If I'm not mistaken, OAuth doesn't alleviate authentication, it just puts the actual username and password out of the regular communication and need to be stored locally, but replaces it with an alternative token, which does need to be stored locally, and passed across the wire. That token now becomes the key to the city, no? In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: > > On Jul 28, 3:27 pm, chinaski007 wrote: > > >> I suppose this is not so weird. Users are accustomed to giving user/ >> pass information even to "foreign" apps. > > > Agree. Anyway, if user just setups desktop app to his computer, he > already gives it much more than just login/password to some service. > And then there is 1000 and 1 way how app can then get all needed info > passing over user. > > > -- > Dmitriy V'jukov
[twitter-dev] Where did Advanced Search go?
>From twitter.com. I'm pretty sure it was there a couple of days ago. Am I not caffeine'ated enough, or is the feature really gone?
[twitter-dev] Re: Search API: since_id is now unreliable
Doug, Is there any status update on this issue? Users are really starting to get frustrated with results and wondering what the status is on things getting back to being consistent... Thanks! Brooks On Jul 21, 3:45 pm, Doug Williams wrote: > Chad,Your assessment is spot on. > > At the heart of search there are a number of data stores that accept queries > (reads) while at the same time perform writes from an indexer. Heavy load -- > large numbers of queries, large number of writes or both, or both -- can > cause the write replication between the indexer and various data stores to > grow inconsistent when a particular data store is blocked on a read. > > Unfortunately there is no easy fix for this problem at the moment. The > search team has grown considerably in the last couple of weeks so as they > get up to speed, the feature set and stability of search should continue to > improve. > > Thanks, > Doug > > > > On Tue, Jul 21, 2009 at 11:57 AM, Chad Etzel wrote: > > > Hi API Team, > > > A few of us have been discussing off list a funky behavior we have > > been noticing and now users are starting to notice. > > > There is a problem for sites/apps like TweetGrid and TweetChat which > > auto-refresh tweets based on the Search API using the since_id. People > > are noticing that these sites are "missing tweets" when compared to > > the search.twitter.com results page for the same query. > > > We believe what is happening is that the search servers are not > > indexing tweets in a serial manner, and so a tweet with a higher id > > may sneak into a search server and be indexed first before a tweet > > with a lower id. This means that when the since_id is sent back from > > the query (or derived from the first result in the results array), > > using that since_id to refresh the query will miss lower id tweets > > when they finally do get indexed. So the illusion of "missing tweets" > > is created. You can run TweetGrid and TweetChat in separate tabs using > > the same query and see that sometimes the results don't match up > > because of this. > > > I'll try to give an example to be clear. > > > Let's say for the sake of simplicity that I'm searching for "twitter" > > and that every 10th tweet in the public timeline matches. So, all > > tweets ending in 0 match my query. > > > Search server 1 may index: > > > 20 > > 30 > > 40 > > 60 > > 70 > > > (notice missing 50) > > > At the same time, Search server 2 may index: > > > 20 > > 30 > > 40 > > 50 > > > (notice hasn't indexed 60 or 70 yet) > > > I send a query and get a response from Server 1 and get a since_id of > > 70. On my next request I use that since_id=70 and I'll never see > > tweet 50. Thus the "missing tweets". > > > This is quite annoying, especially now that users are noticing and > > complaining to us (the app devs) that are apps are broken. > > > I cannot think of a good work around for this that would be simple > > enough to implement and be worth the effort. > > > Is this behavior something anyone else can confirm? Are tweets > > supposed to be indexed/replicated serially by the search servers? > > > -Chad
[twitter-dev] Re: [Twitter4J] Twitter4J 2.0.9 released - introduces tons of bugs, and lots of new features including Android support
Versoin 2.0.9 is not meant to introduce tons of bugs, it actually *fixes* tons of bugs of course. -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] ask first [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://yusuke.homeip.net/blog/ On 2009/07/30, at 2:16, Yusuke Yamamoto wrote: > Hi all, > > Twitter4J 2.0.9 is available for download. > http://yusuke.homeip.net/twitter4j/en/index.html#download > It is(or will be) also available at the Maven central repository. > http://repo1.maven.org/maven2/net/homeip/yusuke/twitter4j/ > Snapshot builds can be found at: > http://yusuke.homeip.net/maven2/net/homeip/yusuke/twitter4j/ > > Release Notes - Twitter4J - Version 2.0.9 - HTML format > Bug > [TFJ-167] - push style streaming thread quits with IOException > [TFJ-173] - " is mapped to \\u0022 > [TFJ-175] - Streaming API now requires comma separated follow > parameter > [TFJ-181] - ExceptionInInitializationError on Android platforms > [TFJ-187] - SerializationException with twitter4j.http.OAuth > [TFJ-189] - TwitterException with streaming API : > twitter4j.TwitterException: JSONObject["id"] not found with > streaming api > Improvement > [TFJ-174] - inconsistent method names in User Methods > [TFJ-177] - the scope of the junit dependencies in the pom should be > set to test > [TFJ-178] - getPublicTimeline(int sinceID) should take long sinceId > [TFJ-179] - scope of junit should be "test", not "compile" > [TFJ-180] - http://twitter.com/statuses/friends_timeline/ > .xml is not supported anymore > [TFJ-182] - ExceptionInInitializerError with Java applets > [TFJ-183] - method name refactor: RateLimitStatus.getDateTime() -> > RateLimitStatus.getResetTime() > New Feature > [TFJ-163] - introduce twitter4j.properties that overrides default > properties > [TFJ-170] - dynamic callback support > [TFJ-176] - Streaming API : support track method > Task > [TFJ-184] - refactor: some fields in HttpClient can be static > [TFJ-190] - slf4j, and rome are not required libraries, scope in > pom.xml should be "provided" instead of "compile" > Cheers, > -- > Yusuke Yamamoto > yus...@mac.com > > this email is: [x] bloggable/tweetable [ ] ask first [ ] private > follow me on : http://twitter.com/yusukeyamamoto > subscribe me at : http://yusuke.homeip.net/blog/ > > >
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 28, 3:27 pm, chinaski007 wrote: > I suppose this is not so weird. Users are accustomed to giving user/ > pass information even to "foreign" apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
