[twitter-dev] Re: Invalid / expired Token for all calls after successful connection made
Just out of curiousity are you supporting the Authorization header form of OAuth when making protected resource requests? I know they work for tokens, but wondered if a call to verify_credentials for instance needed to use parameters or if it could continue to use the Authorization header? On Mar 27, 2:20 am, Dimebrain daniel.cre...@gmail.com wrote: I am able to consistently exchange the request token for the access token and see my application in the Connections tab for my account. However, I'm no longer able to make protected resource requests with the final token and secret. It worked for me earlier in the evening, but now is consistently returning Invalid / expired Token for any authenticated call I make.
[twitter-dev] Re: The OAuth Conundrum
It is a case of tool maturity, but it's a heck of a steep hill to climb up when comparing HTTP Basic Auth to any alternatives. Comparable toolsets for a wide range of languages and environments won't be available for a long time, if ever. In addition, my real concern, as stated above, is with apps and scripts that do automated tasks. These kinds of things frequently execute outside of a modern GUI desktop environment, and all the OAuth workflows I've seen (including your example) have assumed that a graphical web browser is a click away. That's simply not the case with, say, the scripts that pull data down for my data mining experiments. I am afraid that going OAuth-only will effectively kill off these kinds of apps. That would suck, in my opinion. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 26, 1:44 pm, Gavin Bell m...@gavinbell.com wrote: Fair point, there do seem to be more twitter apps than say Flickr apps, but is this not just a case of tool maturity though? It is hard to beat cron and curl, but tools likehttp://intridea.com/2009/3/23/twitter-auth-for-near-instant-twitter-apps will make it easier to get past the auth setup and on to making an interesting app. OAuth is still pretty young compared to basic auth, the tools will get better I think I still think that OAuth as a single framework for web and desktop is a desirable model to aim for. Migrating the current Basic Auth acquired users to OAuth tokens will be a challenge though. registering your OAuthness with twitter.com or responding to a particular API call could then start a token issuing process? On 26 Mar 2009, at 17:19, Ed Finkler wrote: Exactly how I feel Cameron. Use of HTTP Basic Auth has contributed greatly to interesting, unexpected uses of the API, especially those that involve automation. I absolutely feel that the availability of OAuth is a Good Thing, and for many use cases it is practically essential, but it is also unsuitable for some. OAuth as the only authentication scheme will create a much higher barrier for simple exploration of the API. That will be disappointing to me if it happens. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 26, 1:10 pm, Cameron Kaiser spec...@floodgap.com wrote: My friend sent me this blog post [1] (I believe the author is on this list) and though I agree with it generally there is one sentence that really stood out to me it's a fantastic solution to _authenticate other web apps_. After mulling this over I think that this sentence should have been the author's final conclusion. Ideally Twitter would have implemented token based authentication from the start as Flickr did, which would have avoided this whole migration of authentication techniques. However Twitter have said that OAuth is their preferred authentication approach for the future, to roughly quote Doug from Tuesday night's Twitter Devnest meeting. Given that I feel it is much more confusing to have one means of authenticating desktop applications and another for web applications. I think it's hard to say ideally. Ideally *from a security perspective*, sure, but it has been observed and said by many people, not merely yours truly, that Twitter's API would probably not have the wide utilization it does if they had insisted on a token based auth from the very beginning. How many scripts are out there that are basically curl and a cron job? A lot. Unless they can migrate turning off Basic Auth will shut them down, which may or may not be a bad thing, but it was so easy to implement that they became Twitter users. That does count for something. This again should not be construed as a vote of no confidence in OAuth because I'm converting TTYtter (a desktop app) to it too, and there are clear advantages for certain functional domains. But I think it needs to be pointed out that OAuth is not always *the* solution, nor always the best solution in a field of inferior ones. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- I am Pentium of Borg. Division is futile. You will be approximated. --
[twitter-dev] Re: Invalid / expired Token for all calls after successful connection made
When my application had OAuth I was doing all of the requests using OAuth in the headers and it worked fine... Perhaps you are experiencing a transient issues. If you have never been able to make a protected resource request there may be an error in your implementation. Dimebrain wrote: Just out of curiousity are you supporting the Authorization header form of OAuth when making protected resource requests? I know they work for tokens, but wondered if a call to verify_credentials for instance needed to use parameters or if it could continue to use the Authorization header? On Mar 27, 2:20 am, Dimebrain daniel.cre...@gmail.com wrote: I am able to consistently exchange the request token for the access token and see my application in the Connections tab for my account. However, I'm no longer able to make protected resource requests with the final token and secret. It worked for me earlier in the evening, but now is consistently returning Invalid / expired Token for any authenticated call I make.
[twitter-dev] Re: The OAuth Conundrum
I, too, have a bunch of automated scripts accounts that I will be attempting to move to OAuth in the near future. My plan is just to create a dummy app under my main account and then write a simple Get Your Access Token page on my website and use it for each of my bot accounts to create and save access tokens to put in the scripts. I am working with PHP scripts mostly, so using Abe's fantastic TwitterOauth lib makes this rather simple, but I can see how things like a cron job w/ curl or a bash script would be much more difficult. Not sure if a perl lib has been created by anyone yet. Anyone else dealing with the script/automation issue in a different manner? -Chad On Fri, Mar 27, 2009 at 9:52 AM, Ed Finkler funkat...@gmail.com wrote: It is a case of tool maturity, but it's a heck of a steep hill to climb up when comparing HTTP Basic Auth to any alternatives. Comparable toolsets for a wide range of languages and environments won't be available for a long time, if ever. In addition, my real concern, as stated above, is with apps and scripts that do automated tasks. These kinds of things frequently execute outside of a modern GUI desktop environment, and all the OAuth workflows I've seen (including your example) have assumed that a graphical web browser is a click away. That's simply not the case with, say, the scripts that pull data down for my data mining experiments. I am afraid that going OAuth-only will effectively kill off these kinds of apps. That would suck, in my opinion. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 26, 1:44 pm, Gavin Bell m...@gavinbell.com wrote: Fair point, there do seem to be more twitter apps than say Flickr apps, but is this not just a case of tool maturity though? It is hard to beat cron and curl, but tools likehttp://intridea.com/2009/3/23/twitter-auth-for-near-instant-twitter-apps will make it easier to get past the auth setup and on to making an interesting app. OAuth is still pretty young compared to basic auth, the tools will get better I think I still think that OAuth as a single framework for web and desktop is a desirable model to aim for. Migrating the current Basic Auth acquired users to OAuth tokens will be a challenge though. registering your OAuthness with twitter.com or responding to a particular API call could then start a token issuing process? On 26 Mar 2009, at 17:19, Ed Finkler wrote: Exactly how I feel Cameron. Use of HTTP Basic Auth has contributed greatly to interesting, unexpected uses of the API, especially those that involve automation. I absolutely feel that the availability of OAuth is a Good Thing, and for many use cases it is practically essential, but it is also unsuitable for some. OAuth as the only authentication scheme will create a much higher barrier for simple exploration of the API. That will be disappointing to me if it happens. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 26, 1:10 pm, Cameron Kaiser spec...@floodgap.com wrote: My friend sent me this blog post [1] (I believe the author is on this list) and though I agree with it generally there is one sentence that really stood out to me it's a fantastic solution to _authenticate other web apps_. After mulling this over I think that this sentence should have been the author's final conclusion. Ideally Twitter would have implemented token based authentication from the start as Flickr did, which would have avoided this whole migration of authentication techniques. However Twitter have said that OAuth is their preferred authentication approach for the future, to roughly quote Doug from Tuesday night's Twitter Devnest meeting. Given that I feel it is much more confusing to have one means of authenticating desktop applications and another for web applications. I think it's hard to say ideally. Ideally *from a security perspective*, sure, but it has been observed and said by many people, not merely yours truly, that Twitter's API would probably not have the wide utilization it does if they had insisted on a token based auth from the very beginning. How many scripts are out there that are basically curl and a cron job? A lot. Unless they can migrate turning off Basic Auth will shut them down, which may or may not be a bad thing, but it was so easy to implement that they became Twitter users. That does count for something. This again should not be construed as a vote of no confidence in OAuth because I'm converting TTYtter (a desktop app) to it too, and there are clear advantages for certain functional domains. But I think it needs to be pointed out that OAuth is not always *the* solution, nor always the best solution in a field of inferior ones. --
[twitter-dev] Re: What does following in user information do?
Hi there, This is a known issue [1] that I have been working on for some time. I have a fix ready to be deployed next week so hopefully this will start working correctly. Every API user wants and deserves the correct data and the cache should work correctly to keep load off the databases and still return you the correct results. The fix for this bug is a long time coming because we wanted to be sure it would fix the issue, perform well, and be resistant to breaking again in the future. Sorry for the long delay. Thanks; — Matt Sanford [1] - http://code.google.com/p/twitter-api/issues/detail?id=157 On Mar 26, 2009, at 05:15 PM, krwhite wrote: I can report that it's definitely broken in XML. The XML output I see shows a random following result, which suggests to me that the entire result set is a cache from something else. If I may suggest a fix to twitter, how about an extra parameter for 'show_the_right_results' as a boolean? The command would only be slow and uncached for those who would rather have the correct following information. In the future the parameter can just be ignored when it's faster with proper caching. This command is only sent when the user wants extended user information, so it's probably issued the least out of all of them I have implemented. I would assume that's a similar case for other clients. It would be pretty rough on the server as well to use the brute force method of getting ALL followers before displaying follow/unfollow, so I don't see many options right now aside from having multiple, confusing buttons.
[twitter-dev] Re: one-click follow
Hi all, Resurrecting an old thread in order to kill it, or at least wound it. We just deployed a /friendships/add page that is the opposite of / blocks/confirm. Check out http://twitter.com/friendships/add/mzsanford for an example. There are upcoming plans to build out that page some more, so don't everyone reply at once about what's not on there ;). Since this isn't the highest priority change being discussed I wanted to get a minimal version out so people could use it while we talk it over. Thanks; Matt Sanford / @mzsanford On Feb 26, 2009, at 02:40 PM, TjL wrote: On Thu, Feb 26, 2009 at 5:09 PM, Pete Warden searchbrow...@gmail.com wrote: From a UI point of view I'd prefer to have a dedicated Twitter landing page that you could send people to that just contained a 'Do you want to follow X?' rather than having the ubiquitous 'Go to this page and then find the follow button' text on every source page. Just my 2 cents though. :) That's exactly how blocking works. http://twitter.com/blocks/confirm/NAME shows what blocking means and asks if you want to do it. I'd love to see something like: http://twitter.com/follow/confirm/NAME which would explain following and notifications (and give them a chance to turn notifications on/off right there if they have a device defined).
[twitter-dev] Re: Proof of identity rather than authorization
On Thu, Mar 26, 2009 at 7:30 PM, Elliott Kember elliott.kem...@gmail.com wrote: If you don't have a database storing the access tokens or indefinite sessions on your webserver storing them, then the user will have to login everytime. There's no way to get an access token without users going through the OAuth detour. -Chad That's true - but what if the OAuth detour recognizes that the app is already registers, and invisibly allows the authorization, and redirects them to the callback url? For a web-app, this is perfect - it's an invisible roundtrip, similar to OpenID's one. The user probably wouldn't even notice. I guess that would work if the user is already logged into twitter's website and has an active cookie/session going on... but what if they want to login as another user? The auto-callback wouldn't let them do that... They'd have to log out of twitter's website first, but how would they be informed to do that? -Chad In effect, I'm re-authorizing every time, and getting a new access token each time. This will only work for web-apps - but the upside is, a single button-click and you're logged in. Won't have read only access accomplish this? You can check verify_credentials and never check anything else... but the OAuth login flow remains the same.. Sort of - but read-only access can still read DM messages, right? I'm not sure that's necessary for just logging in. On Mar 26, 9:11 pm, Graeme Foster grae...@gmail.com wrote: 2009/3/26 Chad Etzel jazzyc...@gmail.com If you don't have a database storing the access tokens or indefinite sessions on your webserver storing them, then the user will have to login everytime. There's no way to get an access token without users going through the OAuth detour. -Chad In my case I want the client app that is getting and storing its own token to be able to hand something to my web service so the user doesn't have to authorize twice. G.
[twitter-dev] Re: Problem with the limit count with POSTS
Hi there, As part of the OAuth changes I've been planning start restricting the GET/POST operations some more. If you follow this list you have probably noticed that people using POST in place of GET has been the source of many OAuth errors. If that gets added things like this will break, and as a side effect we will correctly enforce the rate limit. While I admire suggesting we keep it this way, it is a work around to one of the things keep our system performing and one of the protections against DOS (be it accidental or not) so that seems unlikely. I'll ask around but I can't say I'll be holding my breath. Thanks; — Matt Sanford / @mzsanford On Mar 26, 2009, at 09:12 PM, Julio Biason wrote: Hi there, I just found a problem with rate limit count. A few days ago, my app (Mitter) started getting weird always 100 remaining requests available all the time. At the time I ignored that. Today I was trying to get the X-RateLimit-Remaining header and there was no way to find out why I was not receiving it. Then it clicked: I added the since_id parameter but, due the way Python urllib2 module behaves, adding it in the body makes a POST request instead of GET. Getting /statuses/friends_timeline.json works fine this way but, because it's a POST, it doesn't count to the limit and the response, also fine, doesn't return the X-RateLimit-Remaining. If possible, I'd suggest to keep things this way, but add the X-RateLimit-Remaining on EVERY request (as it says in the issue) and count every request unless the url is /statuses/update. PS: Before anyone says anything, I found that in the development trunk; the exploit is not in the wild yet. -- Julio Biason julio.bia...@gmail.com Twitter: http://twitter.com/juliobiason
[twitter-dev] Re: one-click follow
OIC, you just want more followers :) This is pretty cool. I am assuming that there will be no additional API call introduced here since friendships/create already does this API-wise? -Chad On Fri, Mar 27, 2009 at 11:20 AM, Matt Sanford m...@twitter.com wrote: Hi all, Resurrecting an old thread in order to kill it, or at least wound it. We just deployed a /friendships/add page that is the opposite of /blocks/confirm. Check out http://twitter.com/friendships/add/mzsanford for an example. There are upcoming plans to build out that page some more, so don't everyone reply at once about what's not on there ;). Since this isn't the highest priority change being discussed I wanted to get a minimal version out so people could use it while we talk it over. Thanks; — Matt Sanford / @mzsanford On Feb 26, 2009, at 02:40 PM, TjL wrote: On Thu, Feb 26, 2009 at 5:09 PM, Pete Warden searchbrow...@gmail.com wrote: From a UI point of view I'd prefer to have a dedicated Twitter landing page that you could send people to that just contained a 'Do you want to follow X?' rather than having the ubiquitous 'Go to this page and then find the follow button' text on every source page. Just my 2 cents though. :) That's exactly how blocking works. http://twitter.com/blocks/confirm/NAME shows what blocking means and asks if you want to do it. I'd love to see something like: http://twitter.com/follow/confirm/NAME which would explain following and notifications (and give them a chance to turn notifications on/off right there if they have a device defined).
[twitter-dev] Re: one-click follow
Hi Chad, Correct. This was just for sites that have a Web UI, want to suggest people to follow, and don't want to collect passwords just for that one action. Things like wefollow.com (though they didn't ask for it) are a prime example. Thanks; — Matt On Mar 27, 2009, at 08:33 AM, Chad Etzel wrote: OIC, you just want more followers :) This is pretty cool. I am assuming that there will be no additional API call introduced here since friendships/create already does this API-wise? -Chad On Fri, Mar 27, 2009 at 11:20 AM, Matt Sanford m...@twitter.com wrote: Hi all, Resurrecting an old thread in order to kill it, or at least wound it. We just deployed a /friendships/add page that is the opposite of /blocks/confirm. Check out http://twitter.com/friendships/add/mzsanford for an example. There are upcoming plans to build out that page some more, so don't everyone reply at once about what's not on there ;). Since this isn't the highest priority change being discussed I wanted to get a minimal version out so people could use it while we talk it over. Thanks; — Matt Sanford / @mzsanford On Feb 26, 2009, at 02:40 PM, TjL wrote: On Thu, Feb 26, 2009 at 5:09 PM, Pete Warden searchbrow...@gmail.com wrote: From a UI point of view I'd prefer to have a dedicated Twitter landing page that you could send people to that just contained a 'Do you want to follow X?' rather than having the ubiquitous 'Go to this page and then find the follow button' text on every source page. Just my 2 cents though. :) That's exactly how blocking works. http://twitter.com/blocks/confirm/NAME shows what blocking means and asks if you want to do it. I'd love to see something like: http://twitter.com/follow/confirm/NAME which would explain following and notifications (and give them a chance to turn notifications on/off right there if they have a device defined).
[twitter-dev] Re: Invalid oAuth Request
Hi there, Is your application registered as read-only by chance? If it is POSTs will fail but the message should be a little more descriptive. Thanks; — Matt On Mar 26, 2009, at 11:34 AM, Baishampayan Ghose wrote: I'm having a little trouble with oAuth - I'm getting an Invalid OAuth Request with a HTTP 401. I'm sure the signature is correct, and all I'm trying to do is get a request token. Has anyone had this problem before and if so how did you fix it? Now I am facing the same problem. For me GET works fine, but POST is giving a 401. Have you faced any better luck yet?
[twitter-dev] Re: Did I miss an OAuth announcement?
Thanks, Brandon. I was following, but tweets get lost in the clutter. I've added it to my rss reader so hopefully I've got the bases covered now. On Mar 25, 4:28 pm, Brandon Geiger bran...@swarmforce.com wrote: you should follow @twitterapi - easier to keep up with announcements regarding the API and OAuth. It went public the 16th. On Mar 25, 2:21 pm, iematthew matthew.dai...@ientryinc.com wrote: The last I heard, OAuth was still in closed beta. I'm assuming any announcements of an official launch would appear in the API Announcements Google group. The last mention of OAuth deployment in the API Announcements group by Matt Sanford stated launching a general release is strongly discouraged: http://groups.google.com/group/twitter-api-announce/browse_thread/thr... I've noticed a certain Twitter app has launched it's OAuth integration on its public website. As I'm not a member of the closed beta, did I miss something, or is this public launch of OAuth functionality premature?
[twitter-dev] Re: The OAuth Conundrum
On Fri, Mar 27, 2009 at 11:00 AM, Chad Etzel jazzyc...@gmail.com wrote: Anyone else dealing with the script/automation issue in a different manner? That's pretty much going to be my plan. Dummy Script Automation of Doom Application and then just a basic webapp that auths and does it's thing for that to get the token that then gets dumped into a config file. -steve
[twitter-dev] Newb OAuth question...
Hey guys, this is probably a pretty basic question - but somehow I haven't been able to find the answer... When a user logs into my web app for the first time using OAuth, and I receive the oauth_access_token and oauth_access_token_secret, I realize I need to save these to the database, but how do I retrieve them next time the user comes back? Say the session has expired, and the user above (who has previously approved access to my app) comes back and hits Login.. how do I look up their access_token secret_access_token, as at this stage I know nothing about them? Thanks, and sorry in advance for what I assume was a lame question :) ./c
[twitter-dev] Re: The OAuth Conundrum
Seriously guys, whats the point in implementing OAuth for stuff like this? Why do you need to delegate access rights to your scripts, your scripts _are_ you, acting as a proxy to the Twitter API as you. OAuth is for delegating access to a third party and is not the right tool for this job, and if everyone implements it then the Twitter developers will have more reason to remove Basic Auth and not provide a proper proxy authentication method. Steve Brunton wrote: On Fri, Mar 27, 2009 at 11:00 AM, Chad Etzel jazzyc...@gmail.com wrote: Anyone else dealing with the script/automation issue in a different manner? That's pretty much going to be my plan. Dummy Script Automation of Doom Application and then just a basic webapp that auths and does it's thing for that to get the token that then gets dumped into a config file. -steve
[twitter-dev] Re: one-click follow
On Fri, Mar 27, 2009 at 11:20 AM, Matt Sanford m...@twitter.com wrote: There are upcoming plans to build out that page some more, so don't everyone reply at once about what's not on there ;). Since this isn't the highest priority change being discussed I wanted to get a minimal version out so people could use it while we talk it over. Thanks! I've already added a Follow link to TwitReport's email report. TjL
[twitter-dev] Re: Newb OAuth question...
2 options: 1) Roll your own authentication or use something like OpenID, Facbook Connect, etc. 2) Send the users through the OAuth flow every time they visit your site. Abraham On Fri, Mar 27, 2009 at 02:29, Chris chris.rick...@gmail.com wrote: Hey guys, this is probably a pretty basic question - but somehow I haven't been able to find the answer... When a user logs into my web app for the first time using OAuth, and I receive the oauth_access_token and oauth_access_token_secret, I realize I need to save these to the database, but how do I retrieve them next time the user comes back? Say the session has expired, and the user above (who has previously approved access to my app) comes back and hits Login.. how do I look up their access_token secret_access_token, as at this stage I know nothing about them? Thanks, and sorry in advance for what I assume was a lame question :) ./c -- Abraham Williams | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: OAuth log in/out behavior
Hi Chad, The oauth authorization login does not propagate sessions to the main site but the oauth logout does blank out your cookies. The combination of these two things is the cause for your issue. During initial development myself and the UX guy used a bunch of test accounts and ran into this. Both of these are included for different reasons and when we looked at how to support this (out of our own laziness) it turned out to be difficult. If there are a bunch of complaints I can look into it again, but if it's a relatively infrequent I hesitate to spend several days fighting it. I know it sounds bad, but better to be honest with you folks … we're all friends here. Thanks; — Matt On Mar 24, 2009, at 10:28 AM, Chad Etzel wrote: I have been encountering this scenario lately (especially with testing OAuth apps with test accounts). Say I am logged into the twitter website under my normal @jazzychad account. I use the site and navigate around, etc.. Now I open another tab and go to log into an OAuth enabed site. I click the link to authenticate. The authentication page knows I am already logged into the main twitter website as @jazzychad, but I want to authenticate using my separate test account instead. I click the link to let me authenticate as somebody else, type in my user/pass and click Allow. I am taken back to the OAuth app and I'm now authenticated. Now I go back to my twitter website tab and click to go somewhere else. Instead of going to my desired page, I find I am now logged out and presented with the Login screen. Obviously this is happening because I authenticated with another account during my OAuth trip. I am wondering if this is something that can be avoided, or if this is a scenario that would affect so few users that it's not really worth worrying about and will just cause a minor annoyance for those actively using multiple accounts -Chad
[twitter-dev] Re: Newb OAuth question...
So say I send them through the OAuth flow everytime, would there then be any reason to persist their access tokens in the DB? as I could just save it to the session when they run through the flow again. On Mar 27, 9:39 am, Abraham Williams 4bra...@gmail.com wrote: 2 options: 1) Roll your own authentication or use something like OpenID, Facbook Connect, etc. 2) Send the users through the OAuth flow every time they visit your site. Abraham On Fri, Mar 27, 2009 at 02:29, Chris chris.rick...@gmail.com wrote: Hey guys, this is probably a pretty basic question - but somehow I haven't been able to find the answer... When a user logs into my web app for the first time using OAuth, and I receive the oauth_access_token and oauth_access_token_secret, I realize I need to save these to the database, but how do I retrieve them next time the user comes back? Say the session has expired, and the user above (who has previously approved access to my app) comes back and hits Login.. how do I look up their access_token secret_access_token, as at this stage I know nothing about them? Thanks, and sorry in advance for what I assume was a lame question :) ./c -- Abraham Williams |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: The OAuth Conundrum
On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry j...@6bit.com wrote: Seriously guys, whats the point in implementing OAuth for stuff like this? Why do you need to delegate access rights to your scripts, your scripts _are_ you, acting as a proxy to the Twitter API as you. If Basic Auth is going to go away at some point in time; well, then we'll have to have this to actually authenticate and authorize the scripts unless some other means becomes available. If Basic Auth is never ever ever ever ever going to go away then you are correct we don't need to worry about doing such delegation to our scripts. I posed the same question earlier and never saw a response or a suggestion that there might be an alternate plan in the works for those of us that do backend internal work of such things, so I'm currently planning the OAuth route. -steve
[twitter-dev] Re: The OAuth Conundrum
Thats exactly what I am saying, just because OAuth is the hammer that the Twitter developers are providing to solve the third party delegation problem doesn't make every problem a nail, and I don't understand why everyone is jumping on board trying to shoehorn OAuth into every authentication scheme. If we as users of the API don't want to subject the users of our applications, or ourselves when writing personal scripts, to OAuth machinations for no reason then we should let the Twitter developers know. Just blindly jumping on the bandwagon is going to give them the impression that everything is great. Use OAuth where it was meant and designed to be used, in the realm of third party delegation and revocation, and leave it there. Steve Brunton wrote: On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry j...@6bit.com wrote: Seriously guys, whats the point in implementing OAuth for stuff like this? Why do you need to delegate access rights to your scripts, your scripts _are_ you, acting as a proxy to the Twitter API as you. If Basic Auth is going to go away at some point in time; well, then we'll have to have this to actually authenticate and authorize the scripts unless some other means becomes available. If Basic Auth is never ever ever ever ever going to go away then you are correct we don't need to worry about doing such delegation to our scripts. I posed the same question earlier and never saw a response or a suggestion that there might be an alternate plan in the works for those of us that do backend internal work of such things, so I'm currently planning the OAuth route. -steve
[twitter-dev] Re: Newb OAuth question...
If you don't need to access the API as the user in between sessions then currently no. On Fri, Mar 27, 2009 at 12:00, Chris chris.rick...@gmail.com wrote: So say I send them through the OAuth flow everytime, would there then be any reason to persist their access tokens in the DB? as I could just save it to the session when they run through the flow again. On Mar 27, 9:39 am, Abraham Williams 4bra...@gmail.com wrote: 2 options: 1) Roll your own authentication or use something like OpenID, Facbook Connect, etc. 2) Send the users through the OAuth flow every time they visit your site. Abraham On Fri, Mar 27, 2009 at 02:29, Chris chris.rick...@gmail.com wrote: Hey guys, this is probably a pretty basic question - but somehow I haven't been able to find the answer... When a user logs into my web app for the first time using OAuth, and I receive the oauth_access_token and oauth_access_token_secret, I realize I need to save these to the database, but how do I retrieve them next time the user comes back? Say the session has expired, and the user above (who has previously approved access to my app) comes back and hits Login.. how do I look up their access_token secret_access_token, as at this stage I know nothing about them? Thanks, and sorry in advance for what I assume was a lame question :) ./c -- Abraham Williams |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. -- Abraham Williams | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from: Madison WI United States.
[twitter-dev] Re: Invalid / expired Token for all calls after successful connection made
Fair enough. I'm most confused about the fact that moving from request_token - access_token doesn't want to use the oauth_token_secret that comes with the initial unauthenticated request token, in fact if I try to hash the signature with that it will fail. I got over that and my implementation is generic enough that I'm using it for all OAuth communication with Twitter, I don't see why the protected resource call would be any different. With verify_credentials where there are no additional parameters, it should be a simple concatenation of GET, URL (account/verify_credentials.xml, etc.), OAuth parameters. It doesn't want to work. I'm going to keep looking at bugs in my implementation code but I shouldn't have gotten this far along to successful access token exchange and then not be able to do the same darn thing for protected resources. Thanks for replying, I'll try to check all my points knowing that you were able to do it with headers without a glitch. On Mar 27, 11:28 am, Joshua Perry j...@6bit.com wrote: When my application had OAuth I was doing all of the requests using OAuth in the headers and it worked fine... Perhaps you are experiencing a transient issues. If you have never been able to make a protected resource request there may be an error in your implementation. Dimebrain wrote: Just out of curiousity are you supporting the Authorization header form of OAuth when making protected resource requests? I know they work for tokens, but wondered if a call to verify_credentials for instance needed to use parameters or if it could continue to use the Authorization header? On Mar 27, 2:20 am, Dimebrain daniel.cre...@gmail.com wrote: I am able to consistently exchange the request token for the access token and see my application in the Connections tab for my account. However, I'm no longer able to make protected resource requests with the final token and secret. It worked for me earlier in the evening, but now is consistently returning Invalid / expired Token for any authenticated call I make.
[twitter-dev] Re: The OAuth Conundrum
It seems to me that Twitter themselves have said (or at least heavily implied) that Basic Auth will GO AWAY in the future. Therefore, OAuth will be the ONLY hammer to use when driving nails. Now, if that stance has changed and Basic Auth will be available forever more, then I am more than happy not to waste my time building OAuth into all of my scripts (I really have better things to do), and Mr. @funkatron will win the day. So far there has been no indication of this, so I am preparing (as well as other devs) for the forthcoming (unannounced as of yet) flag day when The Basic Auth In The Sky Mad Scientist Switch Gate is flipped off by Al3x and Matt wearing lab coats and big goggles while laughing maniacally with Jacob's Ladders sparking madly behind them (I want video of this). It's not because we *want* to, it's because we *have* to. I'm going to trump Dossy here and give his requisite love the bomb speech, blah blah blah... done. Now, let's look at it from another perspective really quick. It could be the case that Twitter decides to leave Basic Auth on forever along side OAuth. It may be that in the twitter app ecosystem (web or desktop/iphone), that apps that use Basic Auth will be shunned by users and ultimately fail b/c everyone is so ga-ga over OAuth finally being the solution for Twitter user security/protection (it's not really, but the illusion is all people want to believe). Thus, apps that want to survive may be forced by peer-pressure to implement OAuth to gain user adoption. The opposite may happen, as has been suggested, that since Basic Auth is so easy for both devs and users alike, that it may still reign supreme as the preferred authentication method, and instead the OAuth apps will be shunned for being too user unfriendly. Who knows what would really happen? It might be a fun experiment to find out, but it's ultimately up to Twitter. Right now the plan laid out before us is OAuth or Nothing, so that's what we're all planning for. -Chad On Fri, Mar 27, 2009 at 1:31 PM, Joshua Perry j...@6bit.com wrote: Thats exactly what I am saying, just because OAuth is the hammer that the Twitter developers are providing to solve the third party delegation problem doesn't make every problem a nail, and I don't understand why everyone is jumping on board trying to shoehorn OAuth into every authentication scheme. If we as users of the API don't want to subject the users of our applications, or ourselves when writing personal scripts, to OAuth machinations for no reason then we should let the Twitter developers know. Just blindly jumping on the bandwagon is going to give them the impression that everything is great. Use OAuth where it was meant and designed to be used, in the realm of third party delegation and revocation, and leave it there. Steve Brunton wrote: On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry j...@6bit.com wrote: Seriously guys, whats the point in implementing OAuth for stuff like this? Why do you need to delegate access rights to your scripts, your scripts _are_ you, acting as a proxy to the Twitter API as you. If Basic Auth is going to go away at some point in time; well, then we'll have to have this to actually authenticate and authorize the scripts unless some other means becomes available. If Basic Auth is never ever ever ever ever going to go away then you are correct we don't need to worry about doing such delegation to our scripts. I posed the same question earlier and never saw a response or a suggestion that there might be an alternate plan in the works for those of us that do backend internal work of such things, so I'm currently planning the OAuth route. -steve
[twitter-dev] Re: Proof of identity rather than authorization
Well, on my site I'll say something like If you're logged in to Twitter already, click here to log in. It works the same way as with OpenID. If they aren't logged into Twitter, they're prompted for their username and password at Twitter's site. Then they're taken straight back to mine. If they want to log in as another user, they have to log out of Twitter - the same way I have to log out of Google to use a different OpenID account. On Mar 27, 3:23 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Mar 26, 2009 at 7:30 PM, Elliott Kember elliott.kem...@gmail.com wrote: If you don't have a database storing the access tokens or indefinite sessions on your webserver storing them, then the user will have to login everytime. There's no way to get an access token without users going through the OAuth detour. -Chad That's true - but what if the OAuth detour recognizes that the app is already registers, and invisibly allows the authorization, and redirects them to the callback url? For a web-app, this is perfect - it's an invisible roundtrip, similar to OpenID's one. The user probably wouldn't even notice. I guess that would work if the user is already logged into twitter's website and has an active cookie/session going on... but what if they want to login as another user? The auto-callback wouldn't let them do that... They'd have to log out of twitter's website first, but how would they be informed to do that? -Chad In effect, I'm re-authorizing every time, and getting a new access token each time. This will only work for web-apps - but the upside is, a single button-click and you're logged in. Won't have read only access accomplish this? You can check verify_credentials and never check anything else... but the OAuth login flow remains the same.. Sort of - but read-only access can still read DM messages, right? I'm not sure that's necessary for just logging in. On Mar 26, 9:11 pm, Graeme Foster grae...@gmail.com wrote: 2009/3/26 Chad Etzel jazzyc...@gmail.com If you don't have a database storing the access tokens or indefinite sessions on your webserver storing them, then the user will have to login everytime. There's no way to get an access token without users going through the OAuth detour. -Chad In my case I want the client app that is getting and storing its own token to be able to hand something to my web service so the user doesn't have to authorize twice. G.
[twitter-dev] Re: The OAuth Conundrum
Hello there, It seems there have been a few threads lately that end in frustration about Basic Auth going away. Going into the OAuth beta we were thinking that we would ideally [1] turn off Basic Auth in the future. Based on the feedback (that's what betas are for, right?) we've seen some usages that don't fit the OAuth model and we're working out what we can do to go on supporting those. Supporting those may mean some addition to OAuth [2] or keeping Basic Auth around in some form [3]. We're still in beta and we have not set a date when Basic Auth will be removed, nor do we know if it ever will. That's what we're trying to figure out during this beta. All of this feedback is helpful but sometimes it borders on FUD I read all of the mails on the list but I don't have time to reply to each one. Let's all say it together: Don't Panic. The low barrier to entry with the Twitter API it a great feature we don't want to lose. We think about it often, and I think about it all of the time in relation to OAuth. I see this as a concern as much as cron jobs and TwitPic integration. Possibly more so since all of those things are bourn of that ease of use. We don't want to lose that ease of use and we're working to find a way to keep that and increase user security. I don't have all of the answers. I suggest people who fit the OAuth flow (webapps, etc) implement it, those that are close (desktop apps) try it, and those that are totally outside of it hang tight. We need some desktop and mobile apps to try it so we can find out what works. Everybody knows it's hard, but if you've used desktop apps with the Flickr API you know it can be done pretty smoothly. Thanks; — Matt Sanford / @mzsanford [1] - Ideally (adv.) - preferably; in a perfect world [2] - http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a8aaef [3] - We're not sure what form. Maybe HTTPS only, using all of the feedback on this list to figure it out. On Mar 27, 2009, at 10:58 AM, Chad Etzel wrote: It seems to me that Twitter themselves have said (or at least heavily implied) that Basic Auth will GO AWAY in the future. Therefore, OAuth will be the ONLY hammer to use when driving nails. Now, if that stance has changed and Basic Auth will be available forever more, then I am more than happy not to waste my time building OAuth into all of my scripts (I really have better things to do), and Mr. @funkatron will win the day. So far there has been no indication of this, so I am preparing (as well as other devs) for the forthcoming (unannounced as of yet) flag day when The Basic Auth In The Sky Mad Scientist Switch Gate is flipped off by Al3x and Matt wearing lab coats and big goggles while laughing maniacally with Jacob's Ladders sparking madly behind them (I want video of this). It's not because we *want* to, it's because we *have* to. I'm going to trump Dossy here and give his requisite love the bomb speech, blah blah blah... done. Now, let's look at it from another perspective really quick. It could be the case that Twitter decides to leave Basic Auth on forever along side OAuth. It may be that in the twitter app ecosystem (web or desktop/iphone), that apps that use Basic Auth will be shunned by users and ultimately fail b/c everyone is so ga-ga over OAuth finally being the solution for Twitter user security/protection (it's not really, but the illusion is all people want to believe). Thus, apps that want to survive may be forced by peer-pressure to implement OAuth to gain user adoption. The opposite may happen, as has been suggested, that since Basic Auth is so easy for both devs and users alike, that it may still reign supreme as the preferred authentication method, and instead the OAuth apps will be shunned for being too user unfriendly. Who knows what would really happen? It might be a fun experiment to find out, but it's ultimately up to Twitter. Right now the plan laid out before us is OAuth or Nothing, so that's what we're all planning for. -Chad On Fri, Mar 27, 2009 at 1:31 PM, Joshua Perry j...@6bit.com wrote: Thats exactly what I am saying, just because OAuth is the hammer that the Twitter developers are providing to solve the third party delegation problem doesn't make every problem a nail, and I don't understand why everyone is jumping on board trying to shoehorn OAuth into every authentication scheme. If we as users of the API don't want to subject the users of our applications, or ourselves when writing personal scripts, to OAuth machinations for no reason then we should let the Twitter developers know. Just blindly jumping on the bandwagon is going to give them the impression that everything is great. Use OAuth where it was meant and designed to be used, in the realm of third party delegation and revocation, and leave it there. Steve Brunton wrote: On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry j...@6bit.com wrote:
[twitter-dev] Re: The OAuth Conundrum
On Fri, Mar 27, 2009 at 4:04 PM, Matt Sanford m...@twitter.com wrote: The low barrier to entry with the Twitter API it a great feature we don't want to lose. We think about it often, and I think about it all of the time in relation to OAuth. I see this as a concern as much as cron jobs and TwitPic integration. Possibly more so since all of those things are bourn of that ease of use. We don't want to lose that ease of use and we're working to find a way to keep that and increase user security. This low bar is what has allowed me ANY access to the Twitter API, because low-bar shell scripts are what I can do. So I just wanted to say thanks for not shutting us off hastily, and if you need folks to talk to about how high is too high to keep the low bar from getting too high then, well, I'm your guy :-) - @TI took a couple of courses in Pascal and decided I didn't want to be a CS major, so I just diddle around with shell scriptsJ
[twitter-dev] Re: The OAuth Conundrum
Hi Paul, In a reply to a previous thread today I mentioned we're working on making that login scenario easier. I am working on it as we speak (or, type, rather). Thanks; — Matt On Mar 27, 2009, at 02:32 PM, Paul Kinlan wrote: Hi matt, I generally like the idea and implementation of oauth and the general flow. My main issue is for the vast amount of sites such as twe2 and twollo that key their accounts off twitter and use twitter as an authentication mechanism now have to introduce a new login mechanism and account managment, which for established sites is not easy to do. We have an oauth login implementation on http://oauth.twe2.com that uses the twitter oauth process nearly every time a user needs to login to our site. I think it works well but is not what oauth is for. I have seen suggestions of using rpxnow, and whilst it is excellent it just adds so much confusion when we have to redirect a twitter user to facebook or google to log in to a twitter app. Those are my issues that most people seem to think are nonplus. Just for information I have seen just 20 requests for oauth on twe2 which is 0.1% of our active userbase (if I have my figures right). Thanks, Paul On 27 Mar 2009, at 20:04, Matt Sanford m...@twitter.com wrote: Hello there, It seems there have been a few threads lately that end in frustration about Basic Auth going away. Going into the OAuth beta we were thinking that we would ideally [1] turn off Basic Auth in the future. Based on the feedback (that's what betas are for, right?) we've seen some usages that don't fit the OAuth model and we're working out what we can do to go on supporting those. Supporting those may mean some addition to OAuth [2] or keeping Basic Auth around in some form [3]. We're still in beta and we have not set a date when Basic Auth will be removed, nor do we know if it ever will. That's what we're trying to figure out during this beta. All of this feedback is helpful but sometimes it borders on FUD I read all of the mails on the list but I don't have time to reply to each one. Let's all say it together: Don't Panic. The low barrier to entry with the Twitter API it a great feature we don't want to lose. We think about it often, and I think about it all of the time in relation to OAuth. I see this as a concern as much as cron jobs and TwitPic integration. Possibly more so since all of those things are bourn of that ease of use. We don't want to lose that ease of use and we're working to find a way to keep that and increase user security. I don't have all of the answers. I suggest people who fit the OAuth flow (webapps, etc) implement it, those that are close (desktop apps) try it, and those that are totally outside of it hang tight. We need some desktop and mobile apps to try it so we can find out what works. Everybody knows it's hard, but if you've used desktop apps with the Flickr API you know it can be done pretty smoothly. Thanks; — Matt Sanford / @mzsanford [1] - Ideally (adv.) - preferably; in a perfect world [2] - http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a8aaef [3] - We're not sure what form. Maybe HTTPS only, using all of the feedback on this list to figure it out. On Mar 27, 2009, at 10:58 AM, Chad Etzel wrote: It seems to me that Twitter themselves have said (or at least heavily implied) that Basic Auth will GO AWAY in the future. Therefore, OAuth will be the ONLY hammer to use when driving nails. Now, if that stance has changed and Basic Auth will be available forever more, then I am more than happy not to waste my time building OAuth into all of my scripts (I really have better things to do), and Mr. @funkatron will win the day. So far there has been no indication of this, so I am preparing (as well as other devs) for the forthcoming (unannounced as of yet) flag day when The Basic Auth In The Sky Mad Scientist Switch Gate is flipped off by Al3x and Matt wearing lab coats and big goggles while laughing maniacally with Jacob's Ladders sparking madly behind them (I want video of this). It's not because we *want* to, it's because we *have* to. I'm going to trump Dossy here and give his requisite love the bomb speech, blah blah blah... done. Now, let's look at it from another perspective really quick. It could be the case that Twitter decides to leave Basic Auth on forever along side OAuth. It may be that in the twitter app ecosystem (web or desktop/iphone), that apps that use Basic Auth will be shunned by users and ultimately fail b/c everyone is so ga-ga over OAuth finally being the solution for Twitter user security/protection (it's not really, but the illusion is all people want to believe). Thus, apps that want to survive may be forced by peer-pressure to implement OAuth to gain user adoption. The opposite may happen, as has been suggested, that since Basic Auth is so
[twitter-dev] How can I automatically retweet from a list of followed accounts?
I'm a complete newbie, so apologies if this isn't an appropriate forum for my question. I would like to set up a Twitter account that automatically retweets the tweets from a list of followed accounts. (I hope that makes sense.) The idea is that a group of people chimes in on a specific topic, and their tweets will be rebroadcast to any and all that are following the main account, but there's administrative control to stop following anyone who behaves badly. This presupposes that the followed accounts would be dedicated, i.e. set up solely for the purpose of twittering to the main account about the topic. Is this sort of thing allowed on Twitter? Are there tools to help, or is there a straightforward solution without tools? Thanks for anything you've got... Jim
[twitter-dev] Fsockopen Over SSL?
I've been playing around using fsockopen to interact with the API but Im
having issues getting ssl to work.
My understanding is the call should look something like this:
@fsockopen('ssl://twitter.com', 443, $errno, $errstr, $this-timeout) but it
always returns a html 400 page. If i drop the ssl:// and switch to port 80
it works fine. It is a GET call to /help/test.xml.
Based on this comment [1] it sounds like Twitters servers don't know how to
handle it.
Has anybody else gotten fsockopen to work on ssl? I've been using the
HttpClient lib [2].
Abraham
[1] http://us3.php.net/manual/en/function.fsockopen.php#84599
[2] http://scripts.incutio.com/httpclient
--
Abraham Williams | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] API usage via SQL 2005 or 2008
Has anyone integrated SQL 2005 or SQL 2008 directly with the twitter API? If so I'd sure love to hear how you've done it. Thanks! Craig
[twitter-dev] getting old posts using the search API
Using the seach API (search.twitter.com/search.json) I would like to be able to retrieve old posts for a given query. I currently use a combination of since_id and until, but, I can only get the last 1500 posts for any given day - the problem being that the until date only specifies the date part. If I had until_id or if the until date took a time (eg 2009-03-02T13:19:00) then I could dial in exactly the range where I left off, working backwards using the previous value of until_id or time. It'd be like using since_id for current messages, but in reverse. But, I can't see any such mechanism. Anybody tried to do this? Any ideas? Thanks
[twitter-dev] ReTweet URL for Blogger
Hey guys ! I looking for a way to create a RETweet link that captures the url and the title. I need to display RT + @MUTWITTERURL + $BloggerPostTitle + $BloggerURL. The idea is pretty similar with what tweetmeme.com does but I want to be able to customize the @MUTWITTERURL. I guess that the length of the post title should be had in mid for creating such link. I found an interesting posting about creating such links using java script here. http://karlo.org/2009/01/add-retweet-links-to-your-blog.html I'm a beginner in twitter app development so I apologize in advance if my posting here sounds a bit silly. I just thought that this was the right place to ask. Thanks !
[twitter-dev] Re: 4-legged OAuth discussion
The workflow you describe has actually always bothered me, and I think is the kind of thing OAuth is trying to combat. Twitpic is not an official service of Twitter, but it seems to be treated as such by many clients, which silently share their users' Twitter authentication information. Any client that shares authentication info with a 3rd-party service without clearly indicating that it's doing so (and offering the option to cancel the action) is, in my opinion, violating the user's trust. I would strongly encourage developers to stop this practice immediately. I think it would be cool to have a one-round OAuth grant to more than one consumer, but *please* make sure that all consumers are broken out and granted access individually. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 25, 8:21 pm, Ivan ivan.kiri...@gmail.com wrote: I started a discussion on the OAuth mailing list about 4-legged OAuth in the context of Twitter OAuth consumer applications.http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a... I'd love to have the input from the Twitter developer community. The problem is essentially that OAuth access tokens aren't transferable. For example, a Twitter user on TweetDeck can input a username password, which lets TweetDeck post a picture to TwitPic. If TweetDeck were granted OAuth access to the user's Twitter account, TwitPic couldn't verify the access tokens easily, and couldn't communicate to Twitter with them. Applications moving to OAuth could mean fewer mashups, which is bad. OAuth providers should have a way of authenticating to Consumer A that Consumer B has access to a user's account. The access to the Twitter API could still require independent OAuth access grants for each consumer. What do you think? Ivanhttp://tipjoy.com
[twitter-dev] Date-based update retrieval
Perhaps I'm completely missing this, but if I can properly authenticate a user in a PHP script, how can I then retrieve their updates for a particular date?
[twitter-dev] Re: Date-based update retrieval
You can use the since parameter for going up to 24 hours old. Otherwise you have to just manually page back until you get what you need. On Fri, Mar 27, 2009 at 23:34, Dan dan.chil...@gmail.com wrote: Perhaps I'm completely missing this, but if I can properly authenticate a user in a PHP script, how can I then retrieve their updates for a particular date? -- Abraham Williams | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from: Madison WI United States.
