Re: [twitter-dev] Re: Upgrading from Read to Read / Write access for OAuth API Key

[Patrick Kennedy]

Apparently there was a bug before (which I now recall), where if the
developer set it to read only, and subsequently changed it to
read-write, it wouldn't really change to read-write.  However, per
earlier conversation in this thread, that issue appears to have
finally been fixed.

So, if you, as the developer, decide to switch an app that is
currently read-only to read-write, it will finally offer the
read-write functionality.  As a developer, you get to choose that
functionality - it won't change without your approval.

~Patrick

On Mon, Jan 31, 2011 at 1: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 <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  | 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 
>> >> 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 
>> >> 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:
>>

Re: [twitter-dev] Re: Upgrading from Read to Read / Write access for OAuth API Key

[Abraham Williams]

Upgraded by going through the authorization flow.

Abraham
-
Abraham Williams | Hacker Advocate | abrah.am
@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  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  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<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  | 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 >
> >  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 

Re: [twitter-dev] Re: Upgrading from Read to Read / Write access for OAuth API Key

[Tom van der Woerdt]

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

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 T