"Sign in" button in popup does not work after changing app's access setting

JanPaul123 · 2013-06-11T13:56:26.000Z

I’ve encountered a possible bug in the Twitter authorize popup.

Steps to reproduce:

Authorize app using OAuth.
Log out of app.
Change app access setting between “read” and “read&write” (in either direction this happens).
Authorize app again using OAuth.
Popup asks to authorize since access setting has changed.
Click “Sign in” to confirm. Nothing happens.

Alternatively:
4. Log in to app using Twitter (“Sign in with Twitter”)
5. Popup asks to authorize since access setting has changed.
6. Click “Sign in” to confirm. Nothing happens.

We’re using a setup with Ruby, Rails, and the “omniauth-twitter” gem, but it seems that the problem is in the Twitter popup page. It simply redirects to the same page over and over. No redirection screen either. No bugs in the Javascript console.

Thanks! Jan Paul

JanPaul123 · 2013-06-13T08:42:00.000Z

This seems a duplicate of https://dev.twitter.com/discussions/16441, but using authorize instead of authenticate (as suggested in https://dev.twitter.com/discussions/14669) has fixed this for me. But in my use case this solution is far from perfect, so it would be great if this bug can be fixed.

DamienVanDev · 2014-06-17T05:53:00.000Z

I was also hit by this bug, changing my app’s permissions from Read/Write down to Read. Afterwards any users who were previously logged in were unable to get past the authorization screen. Pressing the “Sign In” button didn’t do anything.

You can fix it per-user by going into the user’s settings in twitter.com, then into Apps, then revoking permissions to the app. Afterwards authenticate will work as expected (prompting just the first time).

I also tried regenerating the API keys… I can confirm this DOESN’T work so don’t try it to solve the problem.

The only thing that works for sure is using /authorize instead. Since you don’t know ahead of time if a user has one of the bad old tokens or not, you have to force all users through /authorize. That is a really lame situation Too bad this bug is still around, it’s inside a post from twitter to itself and therefore not something that we API users can debug.