"Sign In" button on api.twitter.com no longer works after enabling "Sign in with Twitter"

PatrickTurmala · 2013-04-04T01:27:00.000Z

I need to know why the “Sign in” button takes no action. It used to redirect to my callback URL when I was using “oauth/authorize” as opposed to “oauth/authenticate”. It no longer redirects, but instead removes the access token from the URL on the first click, then, on the second, apparently takes no action at all.

Side question: my application requires the user’s email address in order to sign in with Twitter, which is why I’m taking this route in the first place, so having the “Sign in with Twitter” enabled will cause it to provide the email address, right?

I’m currently using HybridAuth library for social integration with IonAuth for authentication on the CodeIgniter Framework. I have Dovy’s fork of HybridIgniter installed, which can be found here: https://github.com/dovy/HybridIgniter

What is the difference between sign in enable/disabled and can it be affected by me? Thanks in advance.

episod · 2013-04-04T14:57:03.000Z

There’s a corner case where certain apps with certain configurations can end up in this loop – we haven’t fixed it yet. It may have something to do with the permission levels you have configured.

Email address is not shared in any Twitter authentication processes. You would need to ask the user directly for that yourself instead.

PatrickTurmala · 2013-04-06T04:44:14.000Z

Thank you.

DamienVanDev · 2014-06-17T15:34:08.000Z

This bug is still live and very easy to trigger. It happened to me when I changed my app’s permission level. Now I can no longer use authenticate, because users with tokens from the old permission level get stuck on twitter’s authorize page which just posts to itself endlessly with no error message or dialog.

It is not an edge case. Someone changing their permission level is very understandable and it should not then trap all their users in an infinite loop on a twitter.com dialog that posts to itself. (with no explanation of what’s going on).

The only workaround that will not potentially trap users on that page involves giving up using authenticate in favor of authorize and that ruins any chance of one click login from that point forward.

Anyway I look at it, this is clearly a bug on Twitter’s side? It would be great if someone could figure it out because it’s out of our hands as developers and API users. Steps to reproduce it and more discussion are at: https://dev.twitter.com/discussions/18427