Twitter: Latest permission level problems

[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]

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]

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

[ciaranj]

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]

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)