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.