Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Aw: Re: Transmitting csrf-token in the body
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_cool.haxx.se>
Date: Wed, 3 Feb 2021 14:44:26 +0100 (CET)
On Wed, 3 Feb 2021, knurz_at_gmx.at wrote:
> It is an edit token as decribed here:
> https://www.mediawiki.org/wiki/Manual:Edit_token
> The API-documentation for action=edit can be found here:
> https://www.mediawiki.org/wiki/API:Edit/de#API-Dokumentation
First, let me say that none of this is actually curl problems.
This is just a matter of using shell (quoting) and a remote API and curl just
does what you ask it.
> (one difference to the guidance above was that I had to escape the & in the
> last line to get it function)
That's because a bare '&' has a special meaning to shells.
> Oddly enough, if I write the token explicitely instead via $csfr, I have to
> escape the final \: "token=56fd197b14494ae602331fc8516ee282601a69d8+\\"
> Otherwise I get a badtoken-error
That's because a shell quoted string cannot have a single backslash like that,
as the backslash is used as an escape letter and thus has to have something
after it, so you escaped the double-quote and then there was no ending
quote...
> curl --cookie COOKIE_JAR \
> --cookie-jar COOKIE_JAR \
> --form "filename=test.jpg" \
> --form "file=_at_bilder/zionino.jpg" \
> --form "ignorewarnings=1" \
> --form "token= \
> ${WIKI}/api.php?action=edit\&format=json
If I were you, I would add '--trace-ascii dump.txt' to the command line and
check out the dump.txt after the operation to make sure the contents look
exactly like I intended it.
Then it's just a matter of making sure you quote and pass on the token string
correctly in the curl command line.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-03
Date: Wed, 3 Feb 2021 14:44:26 +0100 (CET)
On Wed, 3 Feb 2021, knurz_at_gmx.at wrote:
> It is an edit token as decribed here:
> https://www.mediawiki.org/wiki/Manual:Edit_token
> The API-documentation for action=edit can be found here:
> https://www.mediawiki.org/wiki/API:Edit/de#API-Dokumentation
First, let me say that none of this is actually curl problems.
This is just a matter of using shell (quoting) and a remote API and curl just
does what you ask it.
> (one difference to the guidance above was that I had to escape the & in the
> last line to get it function)
That's because a bare '&' has a special meaning to shells.
> Oddly enough, if I write the token explicitely instead via $csfr, I have to
> escape the final \: "token=56fd197b14494ae602331fc8516ee282601a69d8+\\"
> Otherwise I get a badtoken-error
That's because a shell quoted string cannot have a single backslash like that,
as the backslash is used as an escape letter and thus has to have something
after it, so you escaped the double-quote and then there was no ending
quote...
> curl --cookie COOKIE_JAR \
> --cookie-jar COOKIE_JAR \
> --form "filename=test.jpg" \
> --form "file=_at_bilder/zionino.jpg" \
> --form "ignorewarnings=1" \
> --form "token= \
> ${WIKI}/api.php?action=edit\&format=json
If I were you, I would add '--trace-ascii dump.txt' to the command line and
check out the dump.txt after the operation to make sure the contents look
exactly like I intended it.
Then it's just a matter of making sure you quote and pass on the token string
correctly in the curl command line.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-03