Why is sign-in with twitter no longer transparent for previously authenticated users?

sportily_app · 2013-03-05T09:43:31.000Z

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?

mattrogowski · 2013-03-05T10:18:07.000Z

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.

sportily_app · 2013-03-05T10:36:00.000Z

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.

episod · 2013-03-05T14:20:58.000Z

This blog post explains the changes recently made to the flow: [node:15427].

mattrogowski · 2013-03-05T14:28:01.000Z

Same here

mattrogowski · 2013-03-05T14:30:16.000Z

Thanks!

LibraryThing · 2013-03-05T17:21:31.000Z

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.

craigsssmith · 2013-03-05T17:41:24.000Z

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.

liveensuretoken · 2013-03-18T19:33:03.000Z

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?

episod · 2013-03-18T20:43:33.000Z

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.

liveensuretoken · 2013-03-19T13:44:43.000Z

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.

livewinter · 2013-04-04T21:45:28.000Z

I agree, I suppose there’s nothing we can do to not show that page for 2 seconds right?