Authenticate -> Authorize -> Authenticate loses DM access

#1

We use twitter login as well as allow users to manage their accounts from within our application. Now we have the following scenario in one of our apps :

  1. User logs in using twitter (we use /authenticate)
  2. User add a twitter account (we use /authorize since we need dm access)
  3. User can login any time to the application again ( /authenticate)

After this if the user logs in to our application again using the same account, we lose access to the direct message. The solution is to only use /authorize but then it displays the twitter screen every time a user tries to login to our application.

Is this the expected flow? I understand if the flow was /authorize -> /authenticate then the DM access stays. But what if the flow is /authenticate -> /authorize -> /authenticate ?

#2

Anything on this? I have to use /authorize for signin request and it’s a big pain since the authorize window is displayed each time a user logs in.

#3

I’ll look into this a bit for you – a few questions:

  • Can you share any additional parameters you might pass to the oauth/request_token step or oauth/authorize or oauth/authenticate steps? If you could just list all the parameters you send, it’ll be helpful.

  • What’s the default authorization level set on your application record at this time?

  • Are you sure the users who are being shown the authorization screen on /oauth/authenticate have an existing access token at read-write and direct message level permissions (and not just read-write permissions) – have you done a accounts/verify_credentials request on their behalf and examined the HTTP headers indicating the access level granted?

Thanks

#4

I was trying to find the exact scenario. Seems like very simple to replicate:

  1. /authorize
  2. Log out of twitter
  3. /authenticate (now what happens is twitter displays signin screen with changed permissions)
  4. When user signs in to twitter, the access level goes back to RW

This happens only if the user trying to sign in is logged out of twitter and is presented with the signin screen on /authenticate . If the user is already logged in to twitter then this does not happen.

The default authorization of our app is RWD , and it works well, we’re able to retrieve DMs. Only when the above scenario occurs does the DM access disappear for a users token.

We do not send any extra params to oauth/request_token apart from our callback URL.

#5

What’s “log out of Twitter” in this scenario? Do you completely sign out of Twitter? Does /authenticate not simply re-direct if you don’t log out first? (Trying to narrow the problem area down to whether this only happens when the login sequence is additionally invoked within the OAuth sequence)

#6

“Logout of twitter” - Yeah, completely sign out of twitter. If you do not logout /authenticate simply redirects and everything works fine.

The scenario to be clearer is:

  1. App has RWD access
  2. User is presently not logged in to either twitter.com or the third party app
  3. When user click the ‘sign in with twitter’ button, the app would redirect them to /authenticate
  4. Since user is not logged in to twitter, twitter displays a “Sign In” screen where it explicitly lists out the permissions needed (which in this case would be just RW)

Let me know if you need to know anything. Simply put, if there is any app out there that needs RWD and also offers ‘sign in with twitter’ then they will lose access to ‘D’ once the above scenario occurs.

#7

“Trying to narrow the problem area down to whether this only happens when the login sequence is additionally invoked within the OAuth sequence”

Yes, that’s the exact case when this happens.

#8

anything on this?

#9

Still investigating; a bug is filed with our team. It won’t be fixed in the extremely short-term.

Out of curiosity, for which product features does JustUnfollow utilize DM permissions?

#10

it’s not for justunfollow… it’s for our new app http://www.buffr.com

#11

I presume this bug would affect all apps that need RWD and provide ‘sign in with twitter’. Most wouldn’t realize the error, or probably end up prompting users for DM access every time this bug occurs :frowning:

But I’m also interested in seeing how you guys end up fixing this bug. Since the current sign in window explicitly mentions that "Direct Message’ permission would not be granted, my suggestion would be to specify somewhere informing the user that this holds true only if DM access is not already granted.

#12

Hi,

Sorry to be pestering you but any news if this would be fixed soon?

#13

There’s no news on with this will be fixed yet; it’s a filed bug awaiting prioritization. I will continue to look after it to see that it gets prioritized.

#14

thank you so much :slight_smile:

#15

I’ve noticed this problem as well, following the same flow as @justunfollow …

#16

also another by-product of this issue is that the /authenticate screen will now always prompt the user to sign in whether they’ve previously approved the application or not, which breaks the whole “login with twitter” experience …

#17

Would really like this to get addressed. Any updates.?

A fix would very much help us out on a project we’re nearing the end of.

Thanks guys.

#18

I’d also like to find a resolution for this. Excited to get the login flow worked out for our apps as well.

Thanks for looking into this!

#19

The worst thing about this bug is that not many notice it. And unless your users are really enthusiastic about giving feedback, you as the app developer would have a hard time realizing that your application is facing this problem.

IMO, this should be fixed on priority.

#20

@episod anything on this? This is such an important thing as it breaks the oAuth flow. Users are displayed the sign in screen on every login and it’s annoying them :frowning: