OK, this is killing me. I'm trying to upload files to Commons (using PHP/CURL).
* I can upload local files with my own bot user. * I can upload from remote URLs using OAuth, /if the user is an admin/
What I can't figure out is how to upload local files via OAuth. It's either
"File upload param file is not a file upload; be sure to use multipart/form-data for your POST and include a filename in the Content-Disposition header."
or (trying to add multipart/form-data to the header)
"The authorization headers in your request are not valid: Invalid signature"
Is there any example code for uploading local files to Commons via OAuth? A trick I can't find? Anything?
Cheers, Magnus
I'm guessing the crop tool developer figured it out. That's not one use case I have code for. If anyone has writing code, I'd love a link to it so I can get a demo posted.
There is a trick to getting the form type right, since OAuth's spec explicitly specified out doesn't work with multipart forms. I got it working at one point in or implementation, I'll see if I can dig up that code. On Mar 19, 2014 9:08 AM, "Magnus Manske" magnusmanske@googlemail.com wrote:
OK, this is killing me. I'm trying to upload files to Commons (using PHP/CURL).
- I can upload local files with my own bot user.
- I can upload from remote URLs using OAuth, /if the user is an admin/
What I can't figure out is how to upload local files via OAuth. It's either
"File upload param file is not a file upload; be sure to use multipart/form-data for your POST and include a filename in the Content-Disposition header."
or (trying to add multipart/form-data to the header)
"The authorization headers in your request are not valid: Invalid signature"
Is there any example code for uploading local files to Commons via OAuth? A trick I can't find? Anything?
Cheers, Magnus _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Mar 19, 2014 at 12:07 PM, Magnus Manske <magnusmanske@googlemail.com
wrote:
Is there any example code for uploading local files to Commons via OAuth? A trick I can't find? Anything?
The trick is that you only include the POST data in the signature when the content-type is application/x-www-form-urlencoded. Uploads require multipart/form-data, so you don't include any of the posted fields when calculating the signature (i.e. pretend it's an empty POST when signing).
Hi Brad,
I'm sure that's correct, but:
* When I just sign the OAuth params (no content type, no POST fields), I get "The authorization headers in your request are not valid: Invalid signature" * When I then add the content-type to the header, I get ... the API help page, wrapped in the XML tag <error code="help" info="" xml:space="preserve"> (even though I am querying JSON...)
Apologies if this gets too detailed for the mailing list, it's just very frustrating :-(
On Wed, Mar 19, 2014 at 5:25 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Wed, Mar 19, 2014 at 12:07 PM, Magnus Manske < magnusmanske@googlemail.com
wrote:
Is there any example code for uploading local files to Commons via OAuth? A trick I can't find? Anything?
The trick is that you only include the POST data in the signature when the content-type is application/x-www-form-urlencoded. Uploads require multipart/form-data, so you don't include any of the posted fields when calculating the signature (i.e. pretend it's an empty POST when signing).
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2014-03-19 20:20 GMT+01:00 Magnus Manske magnusmanske@googlemail.com:
Hi Brad,
I'm sure that's correct, but:
- When I just sign the OAuth params (no content type, no POST fields), I
get "The authorization headers in your request are not valid: Invalid signature"
- When I then add the content-type to the header, I get ... the API help
page, wrapped in the XML tag <error code="help" info="" xml:space="preserve"> (even though I am querying JSON...)
Apologies if this gets too detailed for the mailing list, it's just very frustrating :-(
Been there... and yes, it is painful!
I had the same problem while building a python app using OAuth, I was myself receiving the "The authorization headers in your request are not valid: Invalid signature" error.
Eventually I found that in my case the source for the error was the econding of title, since I was doing it (erroneously) two times, so that, for example:
Teatro_comunale_(Bolzano) -> Teatro_comunale_%28Bolzano%29 ->Teatro_comunale_%2528Bolzano%2529
Strangely, the MediaWiki API instead of saying "missing page" it was giving me the invalid request header answer.
I don't know if this is a real bug or simple it was something I should not be doing in the first place, so I did not report it.
About multipart/form-data requests I have made a couple of pull requests to this (python) library by User:Valhallasw: flask-mwoauth. Here's the relevant code: https://github.com/CristianCantoro/flask-mwoauth/commit/ae00d023f9b720c45510...
HTH,
Cristian
2014-03-19 20:34 GMT+01:00 Cristian Consonni kikkocristian@gmail.com:
Eventually I found that in my case the source for the error was the econding of title, since I was doing it (erroneously) two times, so that, for example:
Teatro_comunale_(Bolzano) -> Teatro_comunale_%28Bolzano%29 ->Teatro_comunale_%2528Bolzano%2529
Strangely, the MediaWiki API instead of saying "missing page" it was giving me the invalid request header answer.
I don't know if this is a real bug or simple it was something I should not be doing in the first place, so I did not report it.
I profit of this thread because I would anyway like to know if this behavior is a bug I should report or not.
C
On Wed, Mar 19, 2014 at 3:20 PM, Magnus Manske magnusmanske@googlemail.comwrote:
Hi Brad,
I'm sure that's correct, but:
- When I just sign the OAuth params (no content type, no POST fields), I
get "The authorization headers in your request are not valid: Invalid signature"
- When I then add the content-type to the header, I get ... the API help
page, wrapped in the XML tag <error code="help" info="" xml:space="preserve"> (even though I am querying JSON...)
Apologies if this gets too detailed for the mailing list, it's just very frustrating :-(
It's wikitech, code talk should be expected ;)
I've taken the example code at < https://tools.wmflabs.org/oauth-hello-world/index.php?action=download%3E and changed it to use a multipart/form-data POST; this new version is at < https://tools.wmflabs.org/oauth-hello-world/multipart-formdata.php?action=do.... You'll notice only two changes to the code.
The first (and the important one) is that the call to sign_request() from doApiQuery() only passes the OAuth header fields, not the post fields.
The second is that the call to curl_setopt for CURLOPT_POSTFIELDS from doApiQuery() passes the $post array directly instead of first converting it to a string with http_build_query(). This is what makes curl (or PHP's implementation of it) use multipart/form-data rather than application/x-www-form-urlencoded.
Besides some config and doc changes, everything else remains the same.
I hope this helps.
YES! THANK YOU!
The removal of http_build_query was the missing, secret ingredient. All is well now in my OAuth world!
Thanks again, Magnus
On Thu, Mar 20, 2014 at 2:05 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Wed, Mar 19, 2014 at 3:20 PM, Magnus Manske magnusmanske@googlemail.comwrote:
Hi Brad,
I'm sure that's correct, but:
- When I just sign the OAuth params (no content type, no POST fields), I
get "The authorization headers in your request are not valid: Invalid signature"
- When I then add the content-type to the header, I get ... the API help
page, wrapped in the XML tag <error code="help" info="" xml:space="preserve"> (even though I am querying JSON...)
Apologies if this gets too detailed for the mailing list, it's just very frustrating :-(
It's wikitech, code talk should be expected ;)
I've taken the example code at < https://tools.wmflabs.org/oauth-hello-world/index.php?action=download%3E and changed it to use a multipart/form-data POST; this new version is at <
https://tools.wmflabs.org/oauth-hello-world/multipart-formdata.php?action=do...
.
You'll notice only two changes to the code.
The first (and the important one) is that the call to sign_request() from doApiQuery() only passes the OAuth header fields, not the post fields.
The second is that the call to curl_setopt for CURLOPT_POSTFIELDS from doApiQuery() passes the $post array directly instead of first converting it to a string with http_build_query(). This is what makes curl (or PHP's implementation of it) use multipart/form-data rather than application/x-www-form-urlencoded.
Besides some config and doc changes, everything else remains the same.
I hope this helps.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org