While this makes me happy (from a developers point of view), surely this is a bug and therefore not to be relied on?
As a user, I agree with the logic that if I authorised Read only, the application shouldn't be able to turn this into Read/Write without some subsequent approval. Tim On Jan 31, 1:46 pm, Abraham Williams <4bra...@gmail.com> wrote: > Taylor, > > Confirmed. I just upgraded read only tokens and was able > to successfully send a DM. > > Thank you for finally allowing read only access tokens to be upgraded to > read and write access tokens. This issue has been plaguing developers for > almost a year now. Both forcing applications to ask for permission they > didn't need if there was even a remote possibility they might want write > permissions in the future and biting devs in the ass if they unknowingly > built up a customer base of read only tokens. > > I hope we will continue to see fixes coming down the pipe to keep Twitter > API a viable platform for further development. > > Thank you again, > Abraham > ------------- > Abraham Williams | Hacker Advocate | abrah.am > @abraham <https://twitter.com/abraham> | github.com/abraham | blog.abrah.am > This email is: [ ] shareable [x] ask first [ ] private. > > On Sun, Jan 30, 2011 at 11:19, Taylor Singletary < > > > > > > > > taylorsinglet...@twitter.com> wrote: > > You'll have to re-ask your users for permission for write mode and you > > won't have any way via the API to track who is ready to read/write yet -- > > you'll want to manage the conversion process yourself and track whether > > you've converted your users yet or not. > > > The thinking behind this is that when your users authorized your app, they > > only authorized it for read-access. Wanting write access requires a new > > agreement with the user. > > > The oauth/authorize step should now upgrade to read/write from read-only > > tokens when the user is re-challenged. > > > Taylor > > > On Sun, Jan 30, 2011 at 8:32 AM, Adam Green <140...@gmail.com> wrote: > > >> So if a user authorizes an app for read access, the app can switch to > >> read/write at any time without asking the users permission? Is this > >> true? Anyone from Twitter have any input on this? > > >> On Sun, Jan 30, 2011 at 11:04 AM, Patrick Kennedy <kenned...@gmail.com> > >> wrote: > >> > Tim - > > >> > 1. Changing from read to read/write won't change you API consumer > >> > keys or tokens. > > >> > 2. Your application's users don't authorized for read or read/write; > >> > they merely use your application, which you offer as read or > >> > read/write to the world. That is to say, if it's read, your > >> > application can only read its tweets, and if read/write, it can both > >> > read its own tweet and post to the world. > > >> > I'd say go ahead and switch to read/write, given the fact that you now > >> > want that functionality. > > >> > ~Patrick > > >> > On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull <tim.b...@binaryplex.com> > >> wrote: > >> >> We must be about the only developers in the universe that requested > >> >> users grant only read access when we first got people to connect > >> >>http://trunk.lyto Twitter (I think of the 40 or so apps authorized on > >> >> my account, Trunk.ly is the only one that asks for Read only). Never > >> >> ask for more access than you need is my philosophy. > > >> >> Doh! > > >> >> Of course now, we want to add some Tweet out functions which require > >> >> users grant us Write access. > > >> >> A couple of questions for the Twitter people. > > >> >> 1. If we change the access in the application from read to read/write > >> >> does this reset the API key, or will it stay the same (hoping it stays > >> >> the same). > >> >> 2. How can I work out if existing users have authorised us for read/ > >> >> write? I looked at > >>http://developer.twitter.com/doc/get/account/verify_credentials > >> >> but it doesn't show me what access they have. Do I have to write, > >> >> fail, force them to step through OAuth then post? Or is there a way of > >> >> knowing before hand it will fail and asking them to upgrade? > > >> >> Thanks, > > >> >> Tim > > >> >> -- > >> >> Twitter developer documentation and resources: > >>http://dev.twitter.com/doc > >> >> API updates via Twitter:http://twitter.com/twitterapi > >> >> Issues/Enhancements Tracker: > >>http://code.google.com/p/twitter-api/issues/list > >> >> Change your membership to this group: > >>http://groups.google.com/group/twitter-development-talk > > >> > -- > >> > Twitter developer documentation and resources: > >>http://dev.twitter.com/doc > >> > API updates via Twitter:http://twitter.com/twitterapi > >> > Issues/Enhancements Tracker: > >>http://code.google.com/p/twitter-api/issues/list > >> > Change your membership to this group: > >>http://groups.google.com/group/twitter-development-talk > > >> -- > >> Adam Green > >> Twitter API Consultant and Trainer > >>http://140dev.com > >> @140dev > > >> -- > >> Twitter developer documentation and resources:http://dev.twitter.com/doc > >> API updates via Twitter:http://twitter.com/twitterapi > >> Issues/Enhancements Tracker: > >>http://code.google.com/p/twitter-api/issues/list > >> Change your membership to this group: > >>http://groups.google.com/group/twitter-development-talk > > > -- > > Twitter developer documentation and resources:http://dev.twitter.com/doc > > API updates via Twitter:http://twitter.com/twitterapi > > Issues/Enhancements Tracker: > >http://code.google.com/p/twitter-api/issues/list > > Change your membership to this group: > >http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
