Thanks, I had looked at the docs and totally missed that.
Hasn't fixed my problem though. Now I get "405: method not allowed", the method POST is not allowed for (URL), but that's not the URL I'm trying to submit to, it's the original page with the login form.
The form itself is a little strange, the action of the form is set to a vignette-looking HTML url.
Anyone want to look at the form, at http://users.guardian.co.uk/signin/0,12930,-5,00.html and tell me what might be going wrong?
I should say again, the form can be submitted without JavaScript, so what the point of their weird MD5-hashing of hidden fields and passwords is I don't know.
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply] [d/l] |
I should say again, the form can be submitted without JavaScript
Your question looked pretty interesting, so I took a stab at it. Turns out I can't log in at all using mozilla.
Here's what I tried:
- Turning JavaScript on/off
- Making sure JS has access to create/read cookies
- Masquerading as IE6 on WinXP (ain't the prefbar wonderful?)
- Using IE6 on Win2k
Of these, only using genuine IE worked — they're doing something nefarious.
So, a quick experiment with an HTTP Sniffer reveals that IE POSTs the request, to which the webserver doesn't appear to respond, but it does offer a 301 redirect to another GET request.
I've got absolutely no idea how this works — as I understand HTTP, this shouldn't happen; which probably explains why it doesn't work with Mozilla. Could you show us some (password/username-sanitized) code so we can play with it ourselves?
Update: This bit added
so what the point of their weird MD5-hashing of hidden fields and passwords is I don't know
That appears to be used if JavaScript's enabled (which would probably be for 95% of their users) — it prevents transmission of the password in cleartext. Instead, an MD5 hash of their password with a server-provided challenge is sent. The challenge token probably (hopefully) expires once used, and after a timeout period. This is a pretty effective way of preventing password-sniffing, and because the password entry would still be there for non-JavaScript browsers, it'd work for users without JavaScript (although they'd have to be using a broken browser as discussed above).
cheers
davis
It's not easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day.
| [reply] |
I've got absolutely no idea how this works — as I understand HTTP, this shouldn't happen; which probably explains why it doesn't work with Mozilla. Could you show us some (password/username-sanitized) code so we can play with it ourselves?
I gleaned some of that too, by trying to log in with Lynx. It kept giving me error messages, but you can actually get in with Lynx, because it will say something like "POST doesn't work, want to continue with GET instead?"
I haven't got my code here to show you but essentially what I'd do is get the page with LWP, grab the hidden field values (the "challenges") then construct a form submission to the form's "action" by shoving all the key-value pairs into a string. Something like (pseudocode)
$login = new HTTP::Request($action);
$login->type(www-encoded form);
$login->content('a=1&b=2&c=3');
$useragent->do($login)
and I presume that's what WWW::Mechanize was doing too.
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply] [d/l] [select] |