"Another suggestion, would it hurt to say "Hey, we're thinking about doing X, what do you guys think?" That way we can give you feedback before any firm decisions or deadlines are set".
Lol you're new around here aren't you...... Twitter have never seen developers as equals and don't do things like this. Cheers, Dean ________________________________ From: twitter-development-talk@googlegroups.com [mailto:twitter-development-talk@googlegroups.com] On Behalf Of Derek Gathright Sent: Friday, May 20, 2011 12:09 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: A new permission level Matt Harris said: >> Why are permissions attached to the user token? >> Permissions are attached to the user token to ensure an application only has the access a user has authorised. Only because that is the way the system is currently built, but it doesn't have to be that way (see: Facebook). >> If permissions were not attached to the user token an application would be able to change the level of access they have without the user's knowledge. Not if there were no API for it and permission changes must be done by a user inside twitter.com (the logical thing). For additional security, have an opt-in/out email when permission/settings change on a user's account so they are aware of any changes (see: Banking websites). >> If you tie the permissions to the application each user token would need to be invalidated whenever an application's permissions are changed. Yes, and that's only because that is the way the system currently operates, which is a nuisance for both the developer and user. Imagine if every time I changed any of my Facebook permission settings (a common thing), I had to re-authenticate every. single. app. That eventually leads me to leave permissions as wide-open as possible to avoid the annoying task of re-authentication, defeating the purpose of permissions in the first place. I'm not trying to be argumentative. I understand why it was originally built the way it was and I understand why Twitter is adding the new permission. I'm just saying there are improvements that Twitter should consider to prevent these types of problems going forward. This same outcry will happen next time you add a permission setting, and the time after that, etc... Another suggestion, would it hurt to say "Hey, we're thinking about doing X, what do you guys think?" That way we can give you feedback before any firm decisions or deadlines are set. Those types of conversations used to be very common on this list. Twitter has some smart & talented people working for the company, but there are also many smart & talented people on this list that would love to be involved in these types of things before it becomes an issue and it erupts into a 65+ reply email thread with deadline extensions. On Thu, May 19, 2011 at 5:11 PM, TheGuru <jsort...@gmail.com> wrote: This is where my confusion stemmed from. I'm not sure I was aware of the fact there were 2 OAuth login flows, "web flow" versus "sign in with Twitter". As soon as I flipped the boolean in my PHP include for OAuth to set sign_in_with_twitter = FALSE, so that it would use /authorize instead of /authenticate (sign in with twitter), I then saw the correct permissions on the login page. I'm not sure this is obvious to many devs (it wasn't to me), that there was a difference. I just happened to use / assume "sign in with twitter" was the only web based login available after the implementation of OAuth. What are the implications / reasons for using one method over the other? They seem to essentially do the same exact thing / accomplish the same exact goal. On May 19, 3:17 pm, themattharris <thematthar...@twitter.com> wrote: > The permission level for your application can be edited onhttp://dev.twitter.com/apps. When the website is busy, it can take a > little bit longer for changes to your application to be reflected. > > > Is using a web view against the Terms of Service (TOS)? > > Using an in-app web view to show the OAuth pages is not against our > TOS. However, we encourage developers to use the built-in browser > where appropriate. > > > You said you were restricting this permission to the OAuth /authorize web flow only. Will /oauth/authenticate (Sign in with Twitter) support the new permission? > > 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. > -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk <https://groups.google.com/forum/#%21forum/twitter-development-talk> -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
