Alex, is that *not* estimated or was it an iPhone being daft and
changing now to not?
On Aug 5, 7:11 pm, Alex Payne a...@twitter.com wrote:
The change did not go live yesterday due to some deploy issues. It's
not estimated to go out tomorrow. Once again, sorry for the delay.
On Wed, Aug 5,
We've just heard from our operations and deploy staff that we won't be
able to deploy any code (for the API or otherwise) until Monday due to
the DDoS attack and other issues. That means that the revert to the
old rate limiting policy for this method won't go out this week. My
apologies.
On Thu,
Perhaps a better approach to the lockout:
Lock the account for x minutes after 15 *unique* bad passwords. So if
the user changes their password, and another program keeps trying with
their old password, that only counts as 1 attempt.
It still only gives them 15 guesses, but would cause fewer
Did the rollback happen?
On Aug 3, 6:56 pm, Alex Payne a...@twitter.com wrote:
The rollback should be deployed tomorrow. Sorry for the delay.
On Sat, Aug 1, 2009 at 23:36, Jesse Stayjesses...@gmail.com wrote:
A timeframe would be very helpful. This is turning out to be a headache as
I'm
Would it be possible to have an update on this issue? It seems it's
stifling a lot of developers, me included.
It would appear not - just tried our app and after 15 page loads it
breaks. Our site uses OAuth to sign users in, so we use
verifycredentials on each page request to ensure the session is still
valid and return user details. On our system it is quite likely that
the user will see more than 15
Alex,
Did the change go live on Tuesday?
I have very irate users due to this issue. There are spam bots out
there that got hold of users' credentials. The users have changed
their Twitter passwords to get rid of the spam tweets published in
their timelines, but now those bots are locking them
The change did not go live yesterday due to some deploy issues. It's
not estimated to go out tomorrow. Once again, sorry for the delay.
On Wed, Aug 5, 2009 at 07:48, Dewald Pretoriusdpr...@gmail.com wrote:
Alex,
Did the change go live on Tuesday?
I have very irate users due to this issue.
The rollback should be deployed tomorrow. Sorry for the delay.
On Sat, Aug 1, 2009 at 23:36, Jesse Stayjesses...@gmail.com wrote:
A timeframe would be very helpful. This is turning out to be a headache as
I'm testing. If my own user is having to log in over and over to test my
app, I'm
A timeframe would be very helpful. This is turning out to be a headache as
I'm testing. If my own user is having to log in over and over to test my
app, I'm quickly hitting the verify_credentials limit (and I'm even using
OAuth). I'm getting really frustrated.
Jesse
On Fri, Jul 31, 2009 at 8:01
Hi Doug,
Is there a timescale for rolling back / making the change to the new
scheme?
We're just putting the finishing touches to moving to OAuth and we're
experiencing the issue when using verify_credentials to get the users
basic details once we've got the token back from the authentication
Doug,
I'm in a similar situation as that voiced by TinBlue. This change has
affected our iPhone App. We also want to encourage you to rollback
this change ASAP.
When you say This approach is what we are going to take., do you
mean rolling back the fix so as not to affect multiple, successful,
Ray,For clarity, we will roll back the current restriction of 15 calls per
user per hour to account/verify_credentials, and implement the proposed
scheme:
... we will limit the total number of unsuccessful
attempts to access authenticated resources to 15 an hour per user per IP
address. If a
What is happening?
This rollback is taking far too long for something that has affected a
lot of people!
On Jul 25, 2:32 pm, Dewald Pretorius dpr...@gmail.com wrote:
Doug,
I would prefer to adopt OAuth instead of writing code for Basic Auth.
So, you guys need to move OAuth out of public
Thanks to everyone who has contributed feedback. This approach is what we
are going to take.
Alex will be making this change shortly. I will update this thread when
there is timeframe to share.
Thanks,
Doug
On Mon, Jul 27, 2009 at 7:52 AM, TinBlue tinb...@gmail.com wrote:
What is happening?
Seems fine. Is there a timescale for rolling this out?
On Jul 24, 9:46 pm, Doug Williams d...@twitter.com wrote:
Well said Joshua.
Dewald, you have identified the risk of using basic authentication. If
your users being locked out due to malicious behavior, you should
either implement
Doug,
I would prefer to adopt OAuth instead of writing code for Basic Auth.
So, you guys need to move OAuth out of public beta into full
production sooner rather than later. :-)
I manage 100,000+ Twitter accounts, and I simply cannot take on the
support workload of answering user tickets when
Why will it not apply to OAuth? OAuth is having this problem too!!
Not happy!
On Jul 23, 12:15 am, Doug Williams d...@twitter.com wrote:
Scott,This change will only affect Basic Auth, and will not affect OAuth
applications.
Thanks,
Doug
On Tue, Jul 21, 2009 at 4:27 PM, Scott
What do you mean the change won't affect OAuth? My application has
been suffering from this issue ever since you made the limit change.
My application has the ability to use either Basic or OAuth. My
twitter users get blocked with the 403 error after a few minutes of
usage because they reach the
Jim raised a huge weakness with the authentication rate limiting that
could essentially break third-party apps.
Anybody can try to add anybody else's Twitter account to a third-party
app using an invalid password. If they do that 15 times with a Twitter
account, the real owner of that Twitter
Jim's concern is valid, fortunately OAuth is immune to brute-force
attacks once the access key has been issued to an application. For this
reason alone I would urge people to switch to OAuth if at all possible.
I would hope (and assume) that if login attempts for an account are
locked out
Well said Joshua.
Dewald, you have identified the risk of using basic authentication. If
your users being locked out due to malicious behavior, you should
either implement further user-level rate limiting on your side or
adopt OAuth.
Are there any other glaring omissions in our thinking or
I think Dewald's concern is very valid - and even though OAuth might solve
it, the reality is that most (if not all) desktop and mobile apps are using
Basic Auth today for various reasons, so if you implement this policy as
described, there's a pretty high risk that many users can be locked out of
I would much rather have Twitter lock me out of my account for an hour then
let some script kiddie brute force my password. Thanks Twitter.
Abraham
On Fri, Jul 24, 2009 at 14:51, Marco Kaiser kaiser.ma...@gmail.com wrote:
I think Dewald's concern is very valid - and even though OAuth might
Owkaye,
Thanks for the comment and suggestion.
The problem with implementing this locally at associated web sites
rather than centrally at twitter is that:
- each site would have to implement it separately; and
- users would have to sign up and create a private ID at each site
they use.
That
Jim,
What you're suggesting is basically what they offer with OAuth. Apps
are given a token to represent logins and a secret key to represent
passwords for their authenticated users. Both are very long and
impossible to guess. This mechanism works very well and basically
corrects all the
Making calls to protected methods like direct_messages will fail if the
token is no longer valid. It is also possible that the test method will fail
with incorrect authentication info/oauth token. I have not tried it though.
Abraham
On Wed, Jul 22, 2009 at 03:10, Goblin
My concern with this proposal is that it opens up denials of service,
not to twitter.com, but to associated sites such as twitpic, or my
site twxlate, among others
For example, Lance Armstrong is a heavy user of twitpic. It is very
easy for anyone to find Lance's twitter ID (@lancearmstrong),
One solution to this problem is to add to each twitter
account another private ID.
Jim,
Wouldn't it make more sense to implement this private id
thing on your own server?
My thought here is that your service should maintain its own
database of users, and issue a unique private id for each
Scott,This change will only affect Basic Auth, and will not affect OAuth
applications.
Thanks,
Doug
On Tue, Jul 21, 2009 at 4:27 PM, Scott haw...@gmail.com wrote:
Thanks for the update Doug. Does this still apply to OAuth apps?
Also, if a user goes through an app and unsuccessfully
Thanks for the update Doug. Does this still apply to OAuth apps?
Also, if a user goes through an app and unsuccessfully attempts to
login 15 times will that app be blocked from authenticating anybody
for an hour or just that user? The previous change seemed to block
the entire app from making
To be honest ever since the x-rate-limit HTTP headers were added we
removed the call to verify_credentials from our Twitter API layer.
Every time that our Twitter API layer does an HTTP request it
squirrels away the header values and any requests to our API from the
application for rate-limit
Josh, is there a way, without verify_credentials, to identify that users
have changed their Twitter passwords (and therefore you are no longer able
to authenticate for them)? For client apps, I don't see this being as much
of a problem, but for server-based apps that run regular scripts on behalf
33 matches
Mail list logo
