Подтвердить что ты не робот

PHP, cURL сообщение для входа в WordPress

Я работаю над проектом для клиента, которому требуется автоматический вход в систему из ссылки.

Я использую страницу рукопожатия, чтобы сделать это со следующим кодом:

$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;

Это прекрасно работает. Он записывает меня отлично.

Проблема заключается в том, что я считаю, что ключи WordPress не имеют URL-адреса.

Чтобы уточнить, моя страница рукопожатия (которая входит в систему меня) находится в каталоге "blog", а мое приложение WordPress находится в директории "wordpress", которая находится внутри каталога "blog". URL-адрес в браузере говорит ..blog/handshake.php. Тем не менее, он имеет раздел администратора WordPress в окне браузера. Ссылки в WordPress Admin теперь работают неправильно, потому что URL-адрес находится в каталоге ../blog, когда он должен находиться в каталоге ..blog/wordpress/wp-admin.

Есть ли способ cURL, чтобы URL-адрес в браузере отражал фактическую страницу?

Вместо этого я должен использовать FSockOPen?

4b9b3361

Ответ 1

Kalium получил это право - пути в интерфейсе WordPress относительны, в результате чего интерфейс администрирования не работает должным образом при доступе таким образом.

Ваш подход касается нескольких способов, поэтому я хотел бы сделать несколько быстрых рекомендаций.

Во-первых, я попытался бы найти способ удалить переменные $username и $password из жесткого кодирования. Подумайте, как легко это сломаться - если пароль обновляется через интерфейс администрирования, например, жестко закодированное значение в вашем коде больше не будет корректным, и ваш "автоматический вход" теперь завершится неудачей. Кроме того, если кто-то каким-то образом содержит сайт и получает доступ к handshake.php - ну, теперь у них есть имя пользователя и пароль для вашего блога.

Похоже, что ваша установка WordPress лежит на том же сервере, что и рукопожатие script, которое вы указали, поскольку путь к /blog относительный (в вашем примере кода). Соответственно, я предлагаю попытаться имитировать сеанс, который они проверяют, в вашем логическом входе в родительские приложения. Я делал это несколько раз в прошлом - просто не могу вспомнить специфику. Так, например, ваш логин script не только установит ваши учетные данные для входа, но также установит ключи сеанса, необходимые для аутентификации WordPress.

Этот процесс будет включать в себя копание много кода WordPress, но это красота с открытым исходным кодом! Вместо использования значений cURL и жесткого кодирования попробуйте просто интегрировать механизм аутентификации WordPress в механизм входа в приложение. Я бы начал с изучения источника wp-login.php и оттуда.

Если все остальное терпит неудачу, и вы решили не пытаться объединить механизм проверки подлинности сеанса с механизмом проверки подлинности WordPress, тогда вы можете сразу исправить свою проблему (не исправляя больше аспектов вашего подхода) с этими изменениями в свой код

Сначала добавьте следующий curl_opt:

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

Затем добавьте это после закрытия обработчика cURL:

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();

Итак, в этом менее идеальном решении вы должны использовать cURL для аутентификации пользователя, а затем вместо попытки захватить интерфейс администрирования на эту текущую страницу перенаправить их на обычный интерфейс администрирования.

Надеюсь, это поможет! Дайте мне знать, если вам нужна дополнительная помощь/решение не ясно.

Ответ 2

Проверьте источник HTML. Похоже, что ссылки на WP могут быть относительными. Тем не менее, вместо того, чтобы сделать этот процесс еще более сложным, чем он есть, я предлагаю вам выполнить логин, передать пользователю все файлы cookie и перенаправить их.

В противном случае вы кодируете прокси-сервер, по частям.

Ответ 3

Если ваш script не выполняет все функции, необходимые для одного исполнения, вам может потребоваться проанализировать значения файлов cookie, сохранить их в файле и затем повторно выполнить при следующем выполнении. Проверьте параметр CURLOPT_COOKIEFILE.

Ответ 4

Используйте класс Zend Framework Cookies, чтобы управлять ими для вас. Я использовал это в прошлом для обхода безопасных разделов веб-сайта с помощью cURL.