Hi all

I'm writing an app that will give the user a way to tweet results via
OAuth.  I think I understand the steps involved but I'd like to be sure.
Here's a summary of what I plan to do. A first thing to know is that I plan
to use a cookie to know whether a user has previously used our app.

 - If a user's browser send our cookie, we'll use it to look up the user's
   Access Token and screename, we display their screenname and we know how
   to tweet on their behalf. It seems that long-term storage of Access
   Tokens is encouraged, although they're obviously something to be careful
   with.  Using a cookie to indicate that you've used our site before
   leaves open the possibility for mischief if a user's cookies are
   compromised in some way. Are there better ways to do this?

 - If the browser doesn't send a cookie, we display a sign in with Twitter
   icon http://apiwiki.twitter.com/Sign-in-with-Twitter which when clicked
   initiates the OAuth dance, resulting in us having an Access Token. We
   use that (and our Consumer info) to call account/verify_credentials and
   from the result of that we can extract the user's screenname. We push a
   cookie back to the browser for use next time.

   As I read it, using OAuth does *not* in general result in the Consumer
   getting to know the user's name on the Service Provider. Is that
   correct? Some apps may not need to know it (e.g., you can let the user
   try to navigate to a protected resource and you just send the right
   headers and you're in), but in this case we'd like to know it - perhaps
   just to display the user's screenname, or to pass a screenname or id to
   a method that doesn't require auth but which does require a user name.

Can someone confirm that the above sequence of events is sensible?  BTW,
I'm not looking for explanation of OAuth itself, I'm pretty sure I
understand what's required there, and there are plenty of code samples
around.

Terry

Reply via email to