Recently it seems the behaviour of the sign-in with twitter process changed subtly. It used to be the case that for users that had previously authenticated and authorized my application - when they returned and logged in again that the redirection to twitter was transparent. This no longer appears to be the case - the user it redirected to a twitter page that then redirects back to my web application after a couple of seconds. Is this normal behaviour?
I’m sure something’s changed too because it worked as you described for me until recently, but then without me changing anything I had to authorize the app again every time I logged in. I checked my app settings and ‘Allow this application to be used to Sign in with Twitter’ was unchecked, so I rechecked it and I didn’t have to authorize every time, but now like you said it goes to Twitter first and just says it’s redirecting back to the app which it never used to do. I used to just click sign in and I’d end up back on my site signed in with no other steps.
Great! Well, not great, but at least the behaviour is consistent so that’s something. Out of interest, what platform/libraries are you using to handle the oauth flow? I’m using the PHP twitteroauth (https://github.com/abraham/twitteroauth) library.
This blog post explains the changes recently made to the flow: [node:15427].
I’m having the exact same problem. I’ve enabled the ‘Allow this application to be used to Sign in with Twitter’ but now when i sign it, it never redirects me back to the site and just stays on the authentication screen. whats going on?!
my fault. seems like mine is a different issue, i changed the default permissions and for some reason that is causing the app not to redirect back to my callback_url for some reason. created a new issue about it.
Thanks. The blog post states that the redirection is automatic once the “sign in with twitter” option has been checked. This is the behaviour I am seeing - the redirection is automatic for users who are signed in and have previously authorised my app.
However, this automatic direction used to be transparent to the user, whereas now it is not. Since the changes /oath/authenticate returns a 200 OK response which redirects the user after a couple of seconds.
Thanks for the link Taylor. There’s no specific mention in that blog post regarding the different HTTP response code from oauth/authorize. In the event that the user is currently signed in to twitter and they’ve authorized our app, the previous response was a 302. Now the response in this situation is a 200, with a twitter page containing a meta tag using “http-equiv=refresh” to redirect the user back to our application. This new response breaks some UI elements of our app and I’m wondering if there is any way to tweak our app settings to bring back the old behavior?
We have indeed changed how redirects occur. In what way was your application relying on the specific form of redirect? There is no means to return to the old behavior.
Well thank you for the quick and informative reply Taylor, I appreciate it. With the non-visual (302) style of flow, we were able to present a seamless visual progression through our sign in process to folks using our app. The newer flow shows a brief (1-2 second) view of the twitter authorize page before the refresh send them back to our app. It’s not the end of the world, and our users should not exactly be “surprised” by a brief view of a twitter page when the click the “Sign in with Twitter” button. So, thanks again for following up, and we’ll adjust to deal with the new flow.
I agree, I suppose there’s nothing we can do to not show that page for 2 seconds right?