"Invalid Signature" when POSTing to twitter. about oauth-signpost HOT 23 CLOSED

Some searching has found:
http://groups.google.com/group/twitter-development-talk/msg/6ea8dd6fbee88e9f
which I think may be related, as the given code worked fine a few days prior.

I'm having the same problem, unable to sign POST requests only GET.

"consumer.sign(request)" works fine on GET not on POST..are we missing any 
request
parameters??

The following work around works fine. put the payload into the URL rather than
separately, and set content-length to 0 so that proxies like Squid won't break 
(Squid
requires a content-length on PUT or POST even if there is no content):

----------------------------
final String params = "status=test";
final URL url = new URL("http://twitter.com/statuses/update.xml?" + params);
final HttpURLConnection request = url.openConnection();

request.setRequestMethod("POST");
request.setRequestProperty("Content-Length", "0");
request.setUseCaches(false);
consumer.sign(request);
----------------------------

This suggests that the POST payload isn't being signed correctly.

Wow you are the saviour!!
Thanks a lot Shane that works like a charm! I spent the whole day yesterday and
couldn't find a way round it..
Cheers
Tulio

Because request.getOutputStream() opens the connection I don't think it will be
possible to correctly sign using that method (which I presume is mostly used 
for file
uploads, which aren't covered by oauth.

I'd love to know if there was a better way of doing this than specifying the 
params
in the URL however.

[deleted comment]

[deleted comment]

Thats true, if oauth doesn't support file uploads anyway, users should be 
alright
appending the post data to the URL..If I come across a better way of doing this 
will
definitely let you know
Cheer

Hey guys,

this is not a problem with Twitter, and it's also not actually a bug in 
Signpost.
This problem is a consequence of how HttpURLConnection POSTs work. I already
commented on this issue here: http://groups.google.com/group/signpost-
users/msg/8c9c0b47de68d032

In a nutshell, the problem lies within how data is sent using a URLConnection 
type
request. URLConnection is based around streams. That means, as soon as you add a
payload to your message, you immediately send that data over the wire to the 
service
endpoint. There is no way for Signpost to consider that data for request 
signing,
because it's not buffered and already gone (or not yet there) when signing the 
message.

Hence, since POST params do not pass through message signing, authorization 
fails.

I'll leave this ticket open, but currently I don't see any good solution to 
this.

Just curious: Why do you use URLConnection anyway? Apache HttpComponents or 
JettyHttp would make your life so much easier, and this problem would be non 
existent.

Thanks for the post, will use Apache HttpComponents instead..

I use (HTTP)URLConnection for a few reasons:

The example code for twitter on the wiki used it and I wrote the code based 
around
that so when it came time to POST stuff, i just adapted the code.

Also, I prefer to stick to the built in jdk classes where possible unless there 
is a
compelling reason not to - I don't like needing lots of external dependancies.

(One of the reasons I'm writing my own twitter library rather than using 
another one
is that the one I used in the past didn't support oauth (this is the main 
reason) but
also had about 15 external dependencies that weren't mentioned anywhere)

I appreciate the reason for this not working, I hadn't fully investigated the 
cause
of the problem when I submitted the bug report, and had assumed that because it 
had
worked before twitter fixed their validation that it was possible for signpost 
to see
the submitted data. (I did then try signing after writing out the data which 
gave an
exception that made me realise this was not actually the case)

I'm happy wnough with the work around of putting the parameters into the URL, 
but I
presume theres a better way without needing an external library.

Issue 17 has been merged into this issue.

using Apache HttpComponents and it fails with 401 (invalid signature)-


HttpPut request = new 
HttpPut("http://api.myspace.com/v1/users/475585660/status")         

request.addHeader("Content-Type", "application/x-www-form-urlencoded");
BasicHttpEntity entity = new BasicHttpEntity();
entity.setContent(new StringBufferInputStream("status=hi"));


request.setEntity(entity);
consumer.sign(request);



            // send the request         
HttpClient httpClient = new DefaultHttpClient();
HttpResponse response = httpClient.execute(request);

I don't think your problem is related. This issue report is about POSTing data 
using
HttpURLConnection, which is known to be a problem.

Please turn to the Google Group first and post all details and how your problem 
can
be reproduced, or if you're /sure/ it's a bug, open a new ticket.

Faced same problem with Apache HttpClient. Interesting bit is thatis POSTs ok 
when
httpclient 4.0 but fails with "Invalid Signature" - I changed onli lib used, 
not code. 

Hope it helps someone. The only solution I currently found is to rollback to 
4.0.

Found the source of the problem with Apache HttpClient 4.x (any version could be
affected)

oauth.signpost.signature.SignatureBaseString

    private void collectBodyParameters(Collection<Parameter> parameters)
            throws IOException {

        // collect x-www-form-urlencoded body params
        String contentType = request.getContentType();
        if (contentType != null && contentType.equals(OAuth.FORM_ENCODED)) {   <--- ISSUE
            InputStream payload = request.getMessagePayload();
            parameters.addAll(OAuth.decodeForm(payload));
        }
    }

issue: contentType.equals(OAuth.FORM_ENCODED)
we could see that content type is checked to be equal to
"application/x-www-form-urlencoded", but in real life contentType of POST could 
be
e.g. "application/x-www-form-urlencoded; charset=ISO-8859-1". See RFC-2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

So in this case .equals fails and signpost omits POST params from signature 
calculation.

Yes I'm aware of that problem, will be fixed with the next release (i.e. very 
soon).

I just released 1.2, which fixes this problem.

I'm not gonna fix the problem originally reported. There's enough ways to work 
around 
this (e.g. passing parameters in the query strings or switching to a decent 
HTTP 
library like Apache HttpClient) and fixing this in the lib would require 
hacking 
around the HttpURLConnection implementation.

Sorry folks.

No probs mate, as long as we can get it to work..whether its putting the 
payload in
the URL or using Apache HttpClient then its fine. 

Tulio

[deleted comment]

Issue 35 has been merged into this issue.