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 otherwise - 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: http://help.twitter.com/entries/76915-automation-rules-and-best-practices Happy to clarify the process further for you if you need more help scoping this. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod 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? >
