Incidentally receiving 401 Unauthorized from Twitter (version 1.2.1.1)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Update TwitterAndSignpost sample application to work with signpost  1.2.1.1
2. Modify sample application to perform signing and executing HTTP requests
in loop (e.g. 20 times)
3. Incidentally (2-3 requests on 20) application receives from Twitter
HTTP/1.1 401 Unauthorized,
{"request":"/1/account/verify_credentials.json","error":"Invalid / used nonce"}
4. I attached my sample application used in tests.

What is the expected output? What do you see instead?
This error should never appear.

What version of the product are you using? On what operating system?
Signpost 1.2.1.1, Android 1.5

Please provide any additional information below.
This problem doesn't appear in version 1.1. I compared oauth_nonce value
send by both versions and they are shorter in previous version.

I fixed that problem by changing nonce generator to use Integer instead of
Long (generate shorter oauth_nonce). It helps with Twitter.

Original nonce generator (function from
/signpost-core/src/main/java/oauth/signpost/AbstractOAuthConsumer.java):
    protected String generateNonce() {
        return Long.toString(new Random().nextLong());
    }

Generator with fix:
    protected String generateNonce() {
        return Integer.toString(new Random().nextInt());
    }

Original issue reported on code.google.com by swierch...@gmail.com on 21 Apr 2010 at 11:53

Attachments:

• TwitterAlternativeTest.java

[GoogleCodeExporter]

Missing attachment

Original comment by swierch...@gmail.com on 21 Apr 2010 at 11:58

Attachments:

• TwitterAlternativeTest.java

[GoogleCodeExporter]

I am also facing same problem !!!
Any solution you got ?

Original comment by vdkhakhk...@gmail.com on 17 Sep 2010 at 7:06

[GoogleCodeExporter]

Version 1.2
----------------
We experienced the same problem with 1.2 when generating a lot of OAuth 
requests. We believe the class AbstractOAuthConsumer.java uses a Random in the 
wrong way leading to random number duplicates.

Our quick fix has been through an anonymous extension of the 
"CommonsHttpOAuthConsumer" and overriding the "generateNonce" method . When we 
create a consumer we use the class
<pre>
CommonsHttpOAuthConsumer consumer = new CommonsHttpOAuthConsumer(
                "somekey", "somepassword") {
             // fixed: oauth nonce (random number) generation now thread safe
            @Override
            protected String generateNonce() {
                return Long.toString(RANDOM.nextLong());
            }
        };
</pre>
where the RANDOM is created once using:

    private static final Random RANDOM = new Random();

Version 1.2.1.1
----------------
We just realized that 1.2.1.1 is the newest one. But we still doubt if 
System.nanoTime on line 106 will not fail under excessive load: 

http://code.google.com/p/oauth-signpost/source/browse/trunk/signpost-core/src/ma
in/java/oauth/signpost/AbstractOAuthConsumer.java

There are no tags for 1.2.1.1 so we presume that the trunk and 1.2.1.1 are the 
same.

References:

http://download.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime%
28%29 ("...No guarantees are made about how frequently values change...")
http://download.oracle.com/javase/1.4.2/docs/api/java/util/Random.html ("... If 
two instances of Random are created with the same seed, and the same sequence 
of method calls is made for each, they will generate and return identical 
sequences of numbers....")

Original comment by bun...@gmx.net on 5 Jan 2011 at 12:34

[GoogleCodeExporter]

I've also experienced an issue when signing two requests asynchronously in 
different threads and having 50% of them failing with exact same nonces.

Thanks @bun, I'll try your fix out.

Original comment by grantlan...@gmail.com on 26 Jan 2011 at 6:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Same problem: From Android making 2 requests at same time asynchronously will 
401 one request. @grantlan did it work?

Update: Workaround in comment 3 does work for me

Original comment by michaelb...@gmail.com on 2 May 2011 at 12:20

[GoogleCodeExporter]

@michaelb comment 3 didn't work for me, but creating new OAuthConsumers for 
each request did as per http://code.google.com/p/oauth-signpost/

Thread Safety

Signpost is not thread safe and probably will never be. Signpost objects are 
very lightweight, so you are adviced to create an OAuthConsumer and 
OAuthProvider for every thread in your application that must send signed HTTP 
requests. Both objects are also serializable, so you can persist and restore 
them later.

Original comment by grantlan...@gmail.com on 2 May 2011 at 6:11