PHP, cURL post to login to WordPress

问题:

I am working on a project for a client which needs an automatic login from a link click.

I'm using a handshake page to do this with the following code:

$username = "admin";
$password = "blog";
$url = "http://wordpressblogURL/";
$cookie = "cookie.txt";

$postdata = "log=" . $username . "&pwd=" . $password . "&wp-submit=Log%20In&redirect_to=" . $url . "blog/wordpress/wp-admin/&testcookie=1";
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url . "blog/wordpress/wp-login.php");

curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($ch, CURLOPT_TIMEOUT, 60);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 0);
curl_setopt ($ch, CURLOPT_COOKIEJAR, $cookie);
curl_setopt ($ch, CURLOPT_REFERER, $url . "blog/wordpress/wp-login.php");

curl_setopt ($ch, CURLOPT_POSTFIELDS, $postdata);
curl_setopt ($ch, CURLOPT_POST, 1);
$result = curl_exec ($ch);
curl_close($ch);
echo $result;

exit;

This works fine. It logs me in great.

The problem is that I believe WordPress keys off of the URL.

To elaborate, my handshake page (which logs me in) is in the "blog" directory and my WordPress application is in the "wordpress" directory which sits inside the "blog" directory. The URL in the browser says ..blog/handshake.php. However, it has the Admin section of WordPress in the browser window. WordPress Admin links now do not function correctly, because the URL is in the ../blog directory when it needs to be in the ..blog/wordpress/wp-admin directory.

Is there a way in cURL to make it so that the URL in the browser reflects the actual page?

Should I be using FSockOPen instead?

回答1:

Kalium got this right -- paths in the WordPress interface are relative, causing the administration interface to not work properly when accessed in this manner.

Your approach is concerning in a few ways, so I'd like to make a few quick recommendations.

Firstly, I would try to find a way to remove the $username and $password variables from being hard-coded. Think about how easy this is to break -- if the password is updated via the administration interface, for instance, the hard-coded value in your code will no longer be correct, and your "auto-login" will now fail. Furthermore, if someone somehow comprises the site and gains access to handshake.php -- well, now they've got the username and password for your blog.

It looks like your WordPress installation rests on the same server as the handshake script you've written, given the path to /blog is relative (in your sample code). Accordingly, I'd suggest trying to mimic the session they validate against in your parent applications login. I've done this several times in the past -- just can't recall the specifics. So, for instance, your login script would not only set your login credentials, but also set the session keys required for WordPress authentication.

This process will involve digging through a lot of WordPress's code, but thats the beauty of open source! Instead of using cURL and hard-coding values, try to simply integrate WordPress's authentication mechanism into your application's login mechanism. I'd start by looking at the source for wp-login.php and going from there.

If all else fails and you're determined to not try to mesh your session authentication mechanism with that of WordPress, then you could immediately fix your problem (without fixing the more concerning aspects of your approach) with these changes to your code:

First, add the following curl_opt:

curl_setopt($ch, CURLOPT_COOKIEFILE, $cookie);  // Enables session support

Then, add this after closing the cURL handler:

curl_close($ch);
// Instead of echoing the result, redirect to the administration interface, now that the valid, authenticated session has been established
header('location: blog/wordpress/wp-admin/');
die();

So, in this less than ideal solution you'd use cURL to authenticate the user, and then rather than attempt to hijack the administration interface into that current page, redirect them to the regular administration interface.

I hope this helps! Let me know if you need more help / the solution isn't clear.

回答2:

Check the HTML source. It sounds like WP's links may be relative. Instead of making this process even more complicated than it already is, however, I suggest you perform the login, hand the user whatever cookies are required, and redirect them.

Otherwise you're coding a proxy, piece by piece.

回答3:

If your script doesn't perform all the functions you need in a single execution, you may need to parse out the cookie values, store them in a file, and then resend on the next execution. Check out the CURLOPT_COOKIEFILE option.

回答4:

Use Zend Framework's Cookies class to manage them for you. I have used this in the past for crawling secure sections of a web site using cURL.