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.

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

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

Должен ли я использовать FSockOPen?

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

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

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

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

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

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

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

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

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