Upgraded by going through the authorization flow. 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 Mon, Jan 31, 2011 at 15:34, Tim Bull <[email protected]> wrote: > The way I read Abraham's note, he's saying that by simply upgrading > the token from read to read/write he was able to write? I didn't take > it to mean he had also sent the user to reauthorise? > > T > > On Feb 1, 8:46 am, Tom van der Woerdt <[email protected]> wrote: > > Actually, since the user needs to re-authorize the application, I do not > > think that this is a bug. > > > > Tom > > > > On 1/31/11 10:45 PM, Tim Bull wrote: > > > > > > > > > > > > > > > > > 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<[email protected]> 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< > > > > >> [email protected]> 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<[email protected]> > 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< > [email protected]> > > >>>> 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<[email protected] > > > > >>>> 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.lytoTwitter (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 > -- 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
