Re: curl and form submission
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Jun 09, 2016 at 07:49:28AM +0000, Bob wrote:
>
>
> On Thursday 09 June 2016 07:13 AM, tomas@tuxteam.de wrote:
> >[...]
> >
> >>Thanks for your explanation. I did "curl -c" but no luck as it
> >>doesn't have any cookie.
> >>
> >>curl -c mycookie " http://<link>/login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%40
> >>"
> >>
> >># ls mycookie
> >>ls: cannot access 'mycookie': No such file or directory
> >>
> >>whereas I can see during curl operation
> >>
> >>[....]
> >>
> >><body onload="load();">
> >><form name="myform" method="post" action="http://<link>/login">
> >><input type="hidden" name="username" />
> >><input type="hidden" name="password"/>
> >></form>
> >></body>
> >>
> >>[/...]
> >The form leads explicitly to a POST request. This is one where
> >the data is sent in the HTTP body (and not as query parameters
> >in the URL, as your curl command above is trying).
> >
> >Some web frameworks accept (equivalently) both variants, some
> >not.
> >
> >Try sending as a POST request:
> >
> > curl -X POST -c mycookie \
> > -d username=<user> -d password=<pass> \
> > http://<link>/login
> >
> >(replacing, of course <user>, <pass>, <link> by more interesting
> >values. I've broken up the long line with backslashes, don't type
> >in those).
> >
> >For more on the -d option and its cousins, look them up in the
> >curl man page under --data, --data-ascii, --data-binary and
> >friends.
> >
> >Is anything in the cookiejar yet?
> >
> Issue is, this direct link (which is a redirect link from actual
> form page) doesn't create any cookie jar
>
>
> curl -c mycookie " http://<link>/login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%40
> "
>
> though same is running well on browser and logging in immediately.
>
> --trace-ascii investigation shows as below
>
> ~~~~
> 0000: GET /login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%4
> 0040: 0 HTTP/1.1
> 004c: Host: <link IP>
> 005b: User-Agent: curl/7.47.0
> 0074: Accept: */*
> ...
> ..
> 0300: /head>.<body onload="load();">.<form name="myform" method="post"
> 0340: action="http://1.1.1.1/login";>.<input type="hidden" name="usern
> 0380: ame" />.<input type="hidden" name="password"/>.</form>.</body>.<
Ouch.
This is, as far as I can see, a "javascript redirect". It reflects on
the sad state of our so-called "industry".
As far as I can see, the browser "bounces" the request to
http://1.1.1.1/login with the same fields. So try to direct your
curl request at this (new?) URI. You don't see the browser doing
that (so it seems there's one more back-and-forth)
Of course, the browser is sending more/different stuff in the header,
like the referer, some string for the user agent, etc. The server
might be acting on some of that information.
That's why I suggested spying on what the browser does and trying
to work from there. It's easier to cut off superfluous stuff from
a "known good" case than to try adding stuff blindly.
Get acquainted either with Wireshark (only if your connection isn't
HTTPS! [1]) or with Firebug. It's both free software.
[1] It's possible to spy on an HTTPS connection with Wireshark. But
for that, you'd have to learn how to get your browser to cough
up the session key and to insert that in Wireshark. That raises
the (already pretty high) bar quite a bit.
regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAldZJGoACgkQBcgs9XrR2kZTwACfd28LnYp7qyqAJonUntc+8P/M
XaYAnRrsPSSqV9vJgHjbMf2wqtKr0zxN
=ckK0
-----END PGP SIGNATURE-----
Reply to: