There was some discussion of this at
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/972b23136fdf9ed8/80d6e999d9dedced?hl=en
An attacker who knows your consumer key and consumer secret can create
an application that imitates yours. But they can't impersonate a user
It's a subtle distinction: users aim to use the application, not the
Twitter website. They expect Twitter to ask for their permission, but
they don't expect to start using the Twitter website. So they're a
little surprised when Twitter asks them to log in. The page doesn't
make it clear that
Call setRequestMethod before you call sign. The signature is a
function of the method, among other things.
On Aug 4, 7:18 pm, msea85 carru...@gmail.com wrote:
URL url = new URL(http://twitter.com/statuses/update.xml;);
HttpURLConnection request = (HttpURLConnection) url.openConnection();
http://wiki.oauth.net/ProblemReporting would have been helpful here.
On Aug 5, 3:52 am, Michael E. Carluen mecarl...@gmail.com wrote:
The problem was actually caused by an incorrect server clock setting on the
new server. The server clock was giving a utc offset equivalent to -54000,
which
Re: http://apiwiki.twitter.com/Sign%20in%20with%20Twitter
Would it be practical to change oauth/authenticate, so it's less
challenging to a user who isn't logged in and hasn't authorized the
application? In this case, I'd prefer that the user see a single page
like oauth/authorize, which
User information could be sent together with the OAuth access token
and secret (when exchanging the request token for an access token).
At that point the user's identity has been firmly established. HTTPS
could be used here, to keep the user information private and credible.
On Apr 23, 2:38 pm,
It just dawned on me: it looks like /oauth/authenticate is designed to
merely deliver a user's ID and screen_name to a application, not to
authorize the application to access Twitter on the user's behalf. Is
that so?
A suggestion: treat the user ID and screen_name as a resource that's
protected
I'm having trouble using /oauth/authenticate, too. After
authenticating, Twitter redirects back to my consumer with a different
oauth_token than the one I sent to initiate authentication. Twitter
APIs don't accept either token. Sending the original request token
to /oauth/access_token elicits
It would make more sense to me, too, to use the same protocol flow for
oauth/authorize and /authenticate.
On Apr 16, 11:51 pm, Abraham Williams 4bra...@gmail.com wrote:
It seems like it would make more sense to use the same work flow for both
oauth/authorize and oauth/authenticate. Then the
