Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Twitter: Latest permission level problems #56

Open
dominiek opened this Issue · 8 comments

2 participants

@dominiek

Twitter just changed the way they do permissions and in the app settings you have to specifically authorize access for "direct messages". Normally you don't have to change anything to your app's code, but there is an issue where the new DM permissions are not authorized when the old authorization URL is called: http://twitter.com/oauth/authenticate.

This gets fixed when the newer "http://twitter.com/oauth/authorize" is being called. I recommend we make this change to the twitter auth strategy too. (Line 65, auth.strategies/twitter.js)

@ciaranj
Owner

Thanks, missed this. One question, iirc the two urls differed in their behaviour when the user is already signed in, I thought that 'authenticate' was cleaner in that it would just redirect back immediately, but authorize required user interaction, have I got that wrong?

@dominiek

Actually, you might be right. Going to investigate now

@dominiek

Hmmz, I'm not sure, but their FAQ says:

The R/W/DM permission can only be granted through the /oauth/authorize route. Sign in with Twitter cannot be used to grant R/W/DM.
We understand applications may use other methods of authentication like Sign in with Twitter as well. For this reason, if a user has authorised your application for R/W/DM and you direct them through Sign in with Twitter, we will respect the existing access token permission. This means you can use Sign in with Twitter after a user has authorized your application for R/W/DM.

@dominiek

/oauth/authorize seems to work here. Both for signed in and non-signed in users and authorized and non-authorized apps.

@ciaranj
Owner

Ok, fancy patching and submitting a pull request then (that way you get the credit/blame ;) ) ?

@ciaranj
Owner

Just checked myself, the 'authorize' url does interject with a 'one-click' page even when you're already signed into twitter on that browser, the 'authenticate' doesn't (which seems cleaner.)

Presumably the best solution is to make the twitter strategy configurable so people can decide which approach they want (the former giving the consumer the option of being able to interact with DMs but forcing a user through a visible second page?)

@dominiek

That makes sense. Making this configurable will solve it for now

@ciaranj
Owner

It seems a bit rubbish really (and not a bug according to https://dev.twitter.com/pages/application-permission-model-faq#you-said-you-were-restricting-this-permission-to-the-oauth-authorize-web-flow-only-will-oauthauthenticate-sign-in-with-twitter-support-the-new-permission and less so http://code.google.com/p/twitter-api/issues/detail?id=2257 ) means that if you want to be able to use the same token to do sign-in and send/receive tweets (specifically access DMs) you'll have to introduce a click through on each and every log-in (as you've no way of knowing who the user is in order to determine whether to send them to authenticate or authorize at the point of call)

I imagine the correct solution is to always use 'authenticate' for doing sign in then create a separate side-band application (as mentioned in one of those links) that uses 'authorize' to get an access token that has DM rights. Scopes in connect-auth would allow this to be done relatively easily (but I don't think they're fully fleshed out yet)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.