Re: Update status Using API.
Hi Alex,
I am using this code for posting status ..
?php
include(class.twitter.php);
if(isset($_POST['name']) and isset($_POST['password'])){
$t= new twitter();
$t-username=$_POST['name'];
$t-password=$_POST['password'];
$res = $t-update('i am testing twitter.class.php');
if($res===false){
echo ERRORhr/;
echo pre;
print_r($t-responseInfo);
echo /pre;
}else{
echo SUCCESShr/Status Posted;
}
?
It is display this Error ..
ERROR
Array
(
[url] = http://twitter.com/statuses/update.json
[content_type] = application/json; charset=utf-8
[http_code] = 401
[header_size] = 574
[request_size] = 204
[filetime] = -1
[ssl_verify_result] = 0
[redirect_count] = 0
[total_time] = 0.699
[namelookup_time] = 0.059
[connect_time] = 0.381
[pretransfer_time] = 0.381
[size_upload] = 0
[size_download] = 75
[speed_download] = 107
[speed_upload] = 0
[download_content_length] = 75
[upload_content_length] = 0
[starttransfer_time] = 0.699
[redirect_time] = 0
)
Please tell me what is the problem with this code
Thanks a Ton
Amol
On Nov 14, 11:45 am, Alex Payne [EMAIL PROTECTED] wrote:
Which Twitter PHP class are you using?
On Thu, Nov 13, 2008 at 10:24 PM, Rahul [EMAIL PROTECTED] wrote:
Hi All,
I am new to twitter API :)
I am trying to post status using API ...
Have a look on my code .
?php
include(class.twitter.php);
$twit=new twitter();
$response1=$twit-update(Hi it is working re dada,$_POST
['name'],$_POST['password'] );
?
Please tell me what wrong I am doing..
Thanks
Rahul
--
Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: No OAuth Support just made Techmeme
Cameron Kaiser wrote: 2) I read Alex's E-mail to say, '*sooner* with minimal effort' [but will occur regardless of the effort required], emphasis mine. So far I haven't seen anything to dispute that interpretation. Right. Just like IM to Twitter will eventually come back became sorry, we suck, and gave up on getting IM to Twitter working. I've seen this movie before. I know how it ends. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: No OAuth Support just made Techmeme
We are working on a members website. Users will join create a profile and add things like youtube feeds, images etc, We would like users to be able to add there twitter account details and feed all their tweets into their profile and randomly pull out tweets from different members onto the homepage. Can anyone point out how to do this or where to go to find out how to? Thanks Stephen
statuses/replies.xml and statuses/friends.xml return Not found
Whenever I try to access these REST API URLs, I get a Not found xml error. Are they deprecated, or is this a temporary problem?
Re: Update status Using API.
This library is not coded very accurately. I will post a fixed version within the next few days. My dev computer is currently under-repair, but when its finished (tonight?) I will work and fix this library. In the mean-time, just make the change noted in my previous post and the update() function should work fine.
Re: No OAuth Support just made Techmeme
I'd like to confirm that Cameron's interpretation of email is the intended one. He wrote: I read Alex's E-mail to say, '*sooner* with minimal effort' [but will occur regardless of the effort required], emphasis mine. So far I haven't seen anything to dispute that interpretation. Indeed, where my thinking is at is that we'll do the work necessary to get beta OAuth support out there in our current stack, even if it does mean some duplication of effort as we go forward. As I said, Matt's opinion was that the Rails OAuth plugin/library had improved to the point where we wouldn't have to rework it. If you have questions about our schedule and priorities, just ask. There's no need to speculate. I'm happy to be as open with you all as I can possibly be about why and how we schedule our work, and what our concerns and limitations are when implementing support for a new technology. I would strongly encourage a re-read of Christopher St John's posts is this thread. OAuth is simply a standardization of the token authentication systems that several large companies were making use of. It's not a security silver bullet; token auth has a different threat profile from BasicAuth, but not a non-existent threat profile. At the end of the day, you can hand out your password or hand out a token and you're still giving a potentially malicious application rights to access your data. OAuth's main benefit is that it decouples rights to API access from general access to one's Twitter account. It should also allow users more granular control over which applications have what sort of rights on their behalf. That's good, and something our API and other APIs that make use of BasicAuth sorely lack. The downside is that OAuth suffers from many of the frustrating user experience issues and phishing scenarios that OpenID does. The workflow of opening an application, being bounced to your browser, having to login to twitter.com, approving the application, and then bouncing back is going to be lost on many novice users, or used as a means to phish them. Hopefully in time users will be educated, particularly as OAuth becomes the standard way to do API authentication. Another downside is that OAuth is a hassle for developers. BasicAuth couldn't be simpler (heck, it's got basic in the name). OAuth requires a new set of tools. Those tools are currently semi-mature, but again, with time I'm confident they'll improve. In the meantime, OAuth will greatly increase the barrier to entry for the Twitter API, something I'm not thrilled about. Despite these downsides, we're pushing forward with OAuth, and we'll keep you updated as to our progress. On Fri, Nov 14, 2008 at 8:58 AM, Ed Finkler [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 11:20 AM, Dossy Shiobara [EMAIL PROTECTED] wrote: Ed Finkler wrote: I do understand the frustration, really. But I think I can safely say that the dudes who post here from Twitter bust their ass for you and me, and this kind of thing really doesn't help. So, what would help? Sycophantic cheerleading? I don't think so. Of course not. Suggesting one extreme is not a good idea doesn't imply an opposite extreme is a good idea either. Lets talk about real reasons why it's important for Twitter biz people to up the priority on some kind of reasonable API auth scheme. I think it's Twitter's job to do that. But go for it if you're interested in the exercise. Mainly, I just think there's a difference between saying I really want to see feature A and feature A would be awesome, but I know you guys won't do it. The second one, for me, fails the would I say that to his face? check, so I wouldn't say it in email either. But that's me; you may feel or do differently. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: No OAuth Support just made Techmeme
I'm okay with anything - OAuth or not, so long as we're not forced to store plain-text credentials. Jesse On Nov 14, 2008, at 1:28 PM, Alex Payne wrote: I'd like to confirm that Cameron's interpretation of email is the intended one. He wrote: I read Alex's E-mail to say, '*sooner* with minimal effort' [but will occur regardless of the effort required], emphasis mine. So far I haven't seen anything to dispute that interpretation. Indeed, where my thinking is at is that we'll do the work necessary to get beta OAuth support out there in our current stack, even if it does mean some duplication of effort as we go forward. As I said, Matt's opinion was that the Rails OAuth plugin/library had improved to the point where we wouldn't have to rework it. If you have questions about our schedule and priorities, just ask. There's no need to speculate. I'm happy to be as open with you all as I can possibly be about why and how we schedule our work, and what our concerns and limitations are when implementing support for a new technology. I would strongly encourage a re-read of Christopher St John's posts is this thread. OAuth is simply a standardization of the token authentication systems that several large companies were making use of. It's not a security silver bullet; token auth has a different threat profile from BasicAuth, but not a non-existent threat profile. At the end of the day, you can hand out your password or hand out a token and you're still giving a potentially malicious application rights to access your data. OAuth's main benefit is that it decouples rights to API access from general access to one's Twitter account. It should also allow users more granular control over which applications have what sort of rights on their behalf. That's good, and something our API and other APIs that make use of BasicAuth sorely lack. The downside is that OAuth suffers from many of the frustrating user experience issues and phishing scenarios that OpenID does. The workflow of opening an application, being bounced to your browser, having to login to twitter.com, approving the application, and then bouncing back is going to be lost on many novice users, or used as a means to phish them. Hopefully in time users will be educated, particularly as OAuth becomes the standard way to do API authentication. Another downside is that OAuth is a hassle for developers. BasicAuth couldn't be simpler (heck, it's got basic in the name). OAuth requires a new set of tools. Those tools are currently semi-mature, but again, with time I'm confident they'll improve. In the meantime, OAuth will greatly increase the barrier to entry for the Twitter API, something I'm not thrilled about. Despite these downsides, we're pushing forward with OAuth, and we'll keep you updated as to our progress. On Fri, Nov 14, 2008 at 8:58 AM, Ed Finkler [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 11:20 AM, Dossy Shiobara [EMAIL PROTECTED] wrote: Ed Finkler wrote: I do understand the frustration, really. But I think I can safely say that the dudes who post here from Twitter bust their ass for you and me, and this kind of thing really doesn't help. So, what would help? Sycophantic cheerleading? I don't think so. Of course not. Suggesting one extreme is not a good idea doesn't imply an opposite extreme is a good idea either. Lets talk about real reasons why it's important for Twitter biz people to up the priority on some kind of reasonable API auth scheme. I think it's Twitter's job to do that. But go for it if you're interested in the exercise. Mainly, I just think there's a difference between saying I really want to see feature A and feature A would be awesome, but I know you guys won't do it. The second one, for me, fails the would I say that to his face? check, so I wouldn't say it in email either. But that's me; you may feel or do differently. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Fixes deployed Nov 14th
On Fri, Nov 14, 2008 at 15:15, Alex Payne [EMAIL PROTECTED] wrote: I've just added the first entry to the REST API Changelog at http://apiwiki.twitter.com/REST+API+Changelog. You'll find that we shipped a number of fixes today: Awesome. * Security: statuses of protected users are no longer leaked by adding them as favorites via the API. That sounds like a fun bug. Nearly all of these fixes are thanks to the inimitable Matt Sanford (@mzsanford). If one of these was your pet bug, send him thanks. I read inebriated o_O -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x Nice work. -- | Abraham Williams | Web Developer | http://abrah.am | Brazen Careerist | Pro Hacker | http://www.brazencareerist.com | PoseurTech LLC | Mashup Ambassador | http://poseurte.ch | Web608 | Community Evangelist | http://web608.org | This email is: [] blogable [x] ask first [] private
Re: No OAuth Support just made Techmeme
Jesse Stay wrote: I'm okay with anything - OAuth or not, so long as we're not forced to store plain-text credentials. I just don't want a user's password. A proxy (API key token, OAuth secret, whatever) is better, even if it doesn't afford any extra actual security. Users are educated over and over not to give up their password except to the site that it belongs to. Undoing that by encouraging people to give up their Twitter password is just so frustrating. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: statuses/replies.xml and statuses/friends.xml return Not found
The exact response is: hash request/statuses/friends.xml/request errorNot found/error /hash This occurs even if I try to access http://twitter.com/statuses/friends.xml in the browser, and is still occuring as I post this. On Nov 14, 9:52 am, fastest963 [EMAIL PROTECTED] wrote: Is that all that is sent? A 404 header and Not Found in the content? When did you access the APIs? I know that twitter was having some trouble yesterday with their site, is it still not working?
invalid profile_image_url returned in JSON timeline
In my friends_timeline.json for tweet 1005190499 I'm getting a profile_image_url value of http://s3.amazonaws.com/twitter_production/profile_images/64498715/rollins_narrowweb__300x460_0_normal.jpg -- which is a 404. The correct, working profile image URL that shows up on twitter.com is http://s3.amazonaws.com/twitter_production/profile_images/64499571/rollins_narrowweb__300x460_0_normal.jpg Just so you guys are aware :)
