Twitter badges prompting for Basic Auth login

This is a bug, deployed as part of a related fix to our handling of
web sessions vs API authentication. A fix is pending deploy while we
resolve some issues with our cluster's internal network.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

Hi,

I know this is probably a cheeky questions, what is there an eta for
the fix? My site www.itsabot.com is getting a lot of authentication
problems at the moment.

Kind Regards,
Paul Kinlan.

It's long since fixed.

Hi,

I am seeing problems using the JSON api calls to statuses/user_timeline.json?suppress_response_codes=1 from a webpage (www.itsabot.com) are now comming back saying that the call requires authentication where as in the past the auth cookie went accross with the request from a SCRIPT tab and the data came back.

Now I know "cookie auth" is not supported, but I find it hard to perform any form of useful "hands off" interaction without.  Can you clarify that cookie support to JSON endpoints no longer work?

Many Kind Regards,
Paul Kinlan.

Cookie support was, as you mentioned, never actually support, and it's
definitely disabled. There's a method you can use to find if the user
is logged in, but not WHO the user is. That's intentional.

It's unfortunate, because it did work before yesterday.

I can no longer get the user timeline without a) asking them for a
username and b) using a proxy account.

It is unfortunate again because I have created www.twollo.com which
requires a users username and password and I have been hoping to move
away from that, and now www.itsabot.com no longer has the
interactivity it once had.

I will have to work around it but it just won't be as good and I am
not to pleased because I have 4 more projects in the pipeline that I
am putting on ice.

Regards,
Paul

Apologies. If there's some way that we can help within the realm of
API methods that we support, let me know.

Hehe, I am not sure if there is anything you can do other than support
cookies again :)

From an API point of view for itsabot I need to be able to detect the
current twitter user, whilst the rest of the functionality is accessed
through a proxy using my account and auth details.

I think that it would be good if http referrers to the api could be
whitelisted so that the request could be authenticated but only from
sites approved by twitter.

If there were a referral Whitelist it could be used to reduce the
number of proxy calls I need to make and could also be used to reduce
the chance that people use my proxy for nefareous means.

The good thing about cookies for GET requests is that I don't need to
ask twitter users for any of their details.

From a twollo point of view, several thousand users have used their
password details on the service, now I have to manage and secure this
so that it can auto follow on their behalf. In light of recent
incidents by other services (although it hasn't deterred users of
twollo) I would like to see methods where users can trust my
application to add followers, for instance, without the need for their
twitter details.

Kind regards,

Paul Kinlan

IMO I'd rather you not be able to pull user information out of an existing cookie.  3rd party apps should not be able to read Twitter.com cookies, and vice-versa.  There are a million security concerns about enabling anyone to access this information via cookie - I hope Twitter doesn't enable that.  Rather than detect it through the cookie, it would be better to allow apps to detect the user through the auth processes, via API key and token, in the same manner as Facebook Connect is doing.  Twitter.com should be the only people with access to Twitter.com cookies.  Just my $.02...

Jesse

Hi,

Can I just add that I don't actually do anything with the cookie and I belive it is httpOnly so I couldn't use it if I wanted to.  It just so happened that a SCRIPT reference sent a cookie accross to the twitter services with the json request.

From my point of view I find it hard to find a reason to use a JSON API, if it can't be accessed via a SCRIPT (or some other method).

I can't complain that they stopped the cookie methods, they did say it wasn't supported...

From my point of view, I am trying to develop systems that are as hands off from a user interaction perspective, so asking for a users name (or password in the case of twollo) is an extra step that I don't want to do.

If you look at it from a security angle, the creation actions are POST's so they are locked down in a browser's SCRIPT, all read only requests for "secret" information had already been stopped (i.e listing direct messages).  The rest of the information is public, so I don't think it is a security issue, rather a privacy issue.

Kind Regards,
Paul Kinlan.