Hi Dale,

First a few facts that will help contextualize:

- When you use OAuth to send a given user through the authorization process,
the result is an access token that will be valid as long as the user
continues to allow your application access.
- The access token is in many ways a contract between the user and your
application that gives your application the permission to act as the user on
behalf of their account. As long as the token is valid, your "contract" with
the user that allows you to act on their behalf is in effect.

When moving to OAuth, the first thing you want to do is exchange those
logins and passwords you have for access tokens. You might want to do this
in bulk if you don't want to go to the trouble of writing the authorization
flow and just want to get started from the point of having access tokens. We
offer one-time xAuth access to web applications that you can apply for by
sending a detailed message to a...@twitter.com. xAuth allows you to directly
exchange the logins and passwords you have for access tokens, which you
would then store in your database.

But if you're planning on expanding the pool of users your application uses
at any time you may as well build the entire OAuth authentication flow.

Once you have access tokens for the user accounts you want to act on behalf
of, you'll want to discard the login and passwords stored in your database.
(Unless your company personally controls the accounts in question -- if your
application and the users of your application are all part of the same
organization it's really up to you how you store them).

Whenever you want to make an API call to Twitter, you use the access token
for the user on whose behalf you are acting in conjunction with the other
elements that go into an OAuth request to perform the operation.

So your application would have a model like this:

- One part of the application would be responsible for either taking users
through the OAuth flow or exchanging the logins and passwords for xAuth or
- You would store the access token (made up of an oauth_token and
oauth_token_secret) securely in your database
- When you want to cross-post to multiple accounts, you would post to
/statuses/update.format for each access token making the posting.

Of course, there are many rules outside of the API and OAuth in regards to
automated posting of content:

Happy to clarify the process further for you if you need more help scoping

Taylor Singletary
Developer Advocate, Twitter

On Fri, Apr 30, 2010 at 11:43 AM, Dale <dmdavis....@gmail.com> wrote:

> We have an application at work that periodically collects popular
> article links and posts them to a number of separate twitter accounts.
> Currently, we store the login details for each account in our database
> and access them when we see that there's new content to post.
> I'm trying to figure out how to update the to the new OAuth APIs. I
> saw an one post here where it was suggested that a stored oauth_tokens
> be used to post to the account an app was associated with. Your OAuth
> page on dev.twitter.com has an example of a user logging into an app
> and that app sending the user off to authorization.
> However, neither of these scenarios really matches we're doing. We're
> posting to multiple accounts on behalf of those Twitter accounts.
> They're not online at the time.
> Are there any examples similar to what we're doing that show how we
> can have a single app post to multiple accounts in an automated
> fashion?

Reply via email to