I've been doing development with Android and have a tiny client that
lets me post updates on Twitter via their OAUTH, using the Signpost
library. Since that application is open-source, for the benefit of
all, I've sometimes left my Consumer Token and Secret in files that
I've checked into a public repository. Then I have to go through the
process of getting them changed.

Fortunately, Twitter allows an application to receive new Token and
Secret by going to your app's Twitter page and requesting a reset. The
process is instant. I am the only user of the app, at this point, so I
figured it would be no big deal if I had to re-authenticate. But, it
turned out that the User Token and Secret did not change with the
change in Consumer Token and Secret.

I had assumed that the token and secret for a user were application-
specific, even if I've proven to my satisfaction that they are not
tied to the Consumer token and secret. I had just assumed that.

What is the truth of this. And if I'm being lazy and should just look
it up, that's okay too.

Thanks. This is my first posting here.



On Feb 2, 4:42 am, Blaine Cook <[email protected]> wrote:
> On 1 February 2010 19:58, Onmyouji <[email protected]> wrote:
>
> > It looks like to me that in the spec there is no requirement for some
> > affinity between the Consumer Key/Consumer Secret, and the Access
> > token.
>
> > Is this something that is considered out of scope?
>
> You're right, there's no spec-mandated affinity. However, server-side
> implementations should only allow requests that are made with an
> access token and the consumer key that was used to issue the access
> token. We didn't specify this because there are viable scenarios where
> you want access key portability.
>
> b.

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Reply via email to