Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twitter: Latest permission level problems #56

Open
dominiek opened this issue Jul 1, 2011 · 8 comments
Open

Twitter: Latest permission level problems #56

dominiek opened this issue Jul 1, 2011 · 8 comments

Comments

@dominiek
Copy link

dominiek commented Jul 1, 2011

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
Copy link
Owner

ciaranj commented Jul 1, 2011

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
Copy link
Author

dominiek commented Jul 1, 2011

Actually, you might be right. Going to investigate now

@dominiek
Copy link
Author

dominiek commented Jul 1, 2011

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
Copy link
Author

dominiek commented Jul 1, 2011

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

@ciaranj
Copy link
Owner

ciaranj commented Jul 1, 2011

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

@ciaranj
Copy link
Owner

ciaranj commented Jul 2, 2011

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
Copy link
Author

dominiek commented Jul 3, 2011

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

@ciaranj
Copy link
Owner

ciaranj commented Jul 3, 2011

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants