Perl LWP problems
So I'm trying to solve the Timed Challenge 1. But that's not what this is about, see I use the perl LWP::UserAgent and so on. And in order to get the page with the encoded string, I need to login. Otherwise I get the "You must be logged in to play" message. Here's a snippet of my login code: <Perl Code> use HTTP::Request::Common qw(POST); … $browser=LWP::UserAgent->new; $req=POST $path, ['user_name' => 'icecground', 'user_pass' => $pass, 'remember_me' => 'y' ]; $response=$browser->request($req); $get=$browser->get("http://www.hellboundhackers.org/challenges/timed/timed1/index.php"); </Perl Code>
Why does this not log me in?
Well I don't know any perl, but since noone else seems eager to help, I'll try with what little I can guess from my knowledge and what I could be arsed to look up. Firstly, you might want cookies to be on for later use; secondly, don't use get for a post request. Try this:
$browser->cookie_jar({});
$get=$browser->post("http://www.hellboundhackers.org/challenges/timed/timed1/index.php", ['user_name' => 'icecground', 'user_pass' => $pass, 'remember_me' => 'y' ]);
COM is right on. You first need to setup a cookie jar for the browser. From there, you can do your login at the beginning of the script. If successful, the cookie required for you to be logged in will automatically be read into the cookie jar. Then, you can access pages like a normal logged in user.
On the other hand, you can always setup the cookies you need directly in the cookie jar, assuming you're already logged in through your browser. You can simply use the same php session id, user id, etc. for HBH. Just make sure you update the session id and keep yourself logged in via your browser.
PM me if you need a nudge in the right direction debugging the connection.
you can always use WWW::Mechanize module, which makes using LWP like million times more efficient and easier; you don't need to worry about cookies handling, and it returns a lot of methods for different elements of the webpages you are browsing.
here's sample code to login to hbh
use WWW::Mechanize;
my $url='http://www.hellboundhackers.org/';
my $mech = WWW::Mechanize->new;
$mech->get($url);
$mech->form_with_fields('user_name','user_pass');
$mech->set_fields(user_name=>'clone4',user_pass=>'tryMe');
$mech->click(login);
my $respond = $mech->content;
go and check the module out on cpan, some really useful info there.
Hey, nice to see you posting again, clone <3
As you know and as I said earlier I'm not familiar with Perl and even less so with the module you presented, but looking at your code I have a question. Can that module separate GET from POST requests? Just wondering as both can have forms and you're using something called get() and not post(). Unless of course HBH uses $_REQUEST for login, which I'm assuming it doesn't. From your code I'm assuming you're making two requests, one regular and that it then saves fields from it, fills them out and automatically determines what form of reply to use. Just seems unnecessary to me to make extra requests and it ends up being more code anyhow. Might as well start directly with logging in and use that module to make subsequent requests easier. After all, he has to tell it what fields to fill out and with what anyway.
COM wrote: Hey, nice to see you posting again, clone <3
As you know and as I said earlier I'm not familiar with Perl and even less so with the module you presented, but looking at your code I have a question. Can that module separate GET from POST requests? Just wondering as both can have forms and you're using something called get() and not post(). Unless of course HBH uses $_REQUEST for login, which I'm assuming it doesn't. From your code I'm assuming you're making two requests, one regular and that it then saves fields from it, fills them out and automatically determines what form of reply to use. Just seems unnecessary to me to make extra requests and it ends up being more code anyhow. Might as well start directly with logging in and use that module to make subsequent requests easier. After all, he has to tell it what fields to fill out and with what anyway.
Yeah good to be back :)
Anyhow to answer your question about the method of the request, the module is able to identify the method, and construe the request like the browser would do, so no issue there, and the code will POST the login info. As for the second issue, there was one extra unnecessary line of code (already removed), but you are right the makes two requests instead of one, because we firstly need to obtain the content of the page to identify the form we want to submit. Although we could do it directly by using post() instead of get() with form && click() methods, this way we don't have to worry about cookie handling because that's done for us, not to mention many other advantages, like methods for links, images, forms, as well as other very useful methods used in website processing. I think that is a reasonable trade-off for 1 extra request that we have to make…
So does that mean that if we use post() from the beginning, cookies will not be handled? That seems odd to me, surely they must be if it handles them automatically as they should be set in the header of the initial response. So if it handles data being sent to it, it should logically handle cookies, whether they be set on the first, second or any subsequent response. As the login would make us end up at the main page anyhow and not the challenge page we're after and thus we'll obtain the same content (if not more since we're logged in if we start with post()), I can't see the gain by the extra request. Any material from the page we'd need stored away would be obtained on the upcoming access of the challenge page itself anyhow. All in all, I can't see what exactly the extra first request simplifies or helps. Agreed though that for upcoming page handling the module is very handy, not questioning that, just saying so there won't be any misunderstandings.
Actually you are right, I thought that if you use just post, you would have to bother with saving cookies and then 'attaching' them to every subsequent request manually. As it turns out you don't have to :) I guess it then comes down to laziness and the fact that i consider this way easier then building the post string…
clone4 wrote: actually you are right, I thought that if you use just post, you would have to bother with saving cookies and then 'attaching' them to every subsequent request manually. As it turns out you don't have to :) I guess it then comes down to laziness and the fact that i consider this way easier then building the post string… Hmm, seems easier to me as well as ending up with less code to just build it from the start since you'll have to set the whole thing later on anyhow. But I might've missed something.
Anyhow, I'll take this opportunity to preach what I usually do to people who are trying to work with code related to the web. That is: OP (and anyone else), learn the basics of HTTP, it will not take a lot of time and will make a lot of things much easier. A good tutorial can be found here: http://www.jmarshall.com/easy/http/
icecground wrote: Hey all! The LWP::UserAgent didn't work with the cookies either… Guess I'm doing something wrong. Anyways, I got the Mechanize to fix it for me. And it did. Creds to Clone4 for the help. Now ima go fix the mission :P Btw this thread is done so it should probably be locked or something… Of course the cookies didn't solve it on their own. They're not worth much if you don't log in with a post. Anyhow, creds were already given when he made the post, so don't worry bout that.