Я работаю над сайтом, для которого требуется защищенная административная область https, а также безопасная область переднего плана, где будет отображаться личная информация. Я предпочитаю для входа пользователя виджет с поддержкой Ajax, который может отображаться на каждой странице сайта, но я не могу заставить его работать при передаче отправленных данных формы с незащищенных страниц на страницу входа.
Я начал с использования плагина Login With Ajax, который с некоторыми модификациями хорошо работает с SSL по большей части, и он отлично работает при входе со страницы, доступ к которой осуществляется через https… и он также отлично работает, когда FORCE_SSL_ADMIN выключен. Но при попытке войти из виджета на незащищенную страницу с включенным FORCE_SSL_ADMIN не могу получить ответ от сервера.
Существуют ли какие-либо существующие плагины, решающие эту проблему? А если нет, то есть у кого решения? Может быть, защищенная форма, встроенная в iframe, — моя лучшая идея на данный момент… просто думаю, что должен быть более простой способ.
*Редактировать: Предлагая награду*
Я добавляю награду к этому вопросу, потому что мне все еще любопытно. Я обошел это в своем проекте, просто отказавшись от виджета и отобразив ссылку на страницу wp-login. Но возможность встроить безопасную форму входа на незащищенную страницу была бы гораздо лучшим решением. Я присуждаю награду любому, кто может показать код, который будет работать, чтобы это произошло, или укажет мне на плагин, который уже делает это.
Итак, у вас есть незащищенная страница, на которой вы отображаете форму, которая будет отправлена на безопасную страницу? Проблема здесь в том, что злоумышленник может изменить вашу незащищенную страницу входа, чтобы форма входа отправлялась на его собственный сервер и, таким образом, получала всю информацию для входа и пароля.
Да, в качестве модели того, что я надеялся сделать, я смотрел на традиционный банковский веб-сайт, где есть безопасная форма входа, встроенная в качестве src iframe на страницу, которая не обязательно защищена. После прочтения вашей ссылки и других критических замечаний по безопасности, таких как (эта) [ my.opera.com/yngve/blog/show.dml/281609], я думаю, что согласен с тем, что это не обязательно хорошая идея. Но я все равно оставлю свою награду, пока не выясню, как заставить ее работать.
Небольшой совет по редактированию: для встраивания ссылок вы делаете это наоборот, поэтому он становится
[link text](link destination).Жаль, что src iframe может быть изменен на незашифрованной главной странице. Безопасность… Не могу с ней жить, не могу без нее.
Если кому-то удастся получить контроль над некоторыми серверами имен и подделать мой сайт… думаю, это не в моей власти. Конечно, я думаю, они также могут подделать сертификат безопасности. Я не использую один из сертификатов расширенной проверки, а просто стандартное шифрование «синяя полоса».
Я прочитаю эти заметки и посмотрю, помогут ли они мне. Это единственное, в чем я не уверен… не совсем уверен, почему это необходимо и соответствует ли действие wp-login.php redirect_to этому описанию: безопасный URL-адрес, на который отправляется форма, всегда должен возвращать перенаправление 302 вернуться к незащищенному URL-адресу.
Возврат пользователя к незащищенному URL-адресу в результате формы POST, вероятно, связан с тем, чтобы избежать сообщений «страница содержит как безопасные, так и небезопасные элементы» от браузера и / или обеспечить возможность вызова
parent.handleLogin()функции или ее эквивалента. (Я не могу легко найти информацию о том, как работают вызовы JS с защищенной страницы на незащищенную страницу.)@dgw ПРЕДОСТАВЛЕННАЯ ССЫЛКА БОЛЬШЕ НЕ РАБОТАЕТ. Извините за крик — просто чтобы предупредить последующих читателей. Одна из причин, почему ссылки не должны быть ответом. Пожалуйста, всегда добавляйте содержание ссылок к вашему вопросу.
Более поздние читатели обнаружат, что ссылка больше не работает сама по себе, не так ли? Я не уверен, что кричать было необходимо. Все равно похоже на временную ошибку.
Вау, эта презентация была невероятно полезной и тщательной… Тем не менее, она не помогла мне решить мою проблему. Что вы имеете в виду о разнице между http и https? Где всплывает проблема?
Хм… это вполне может быть моей проблемой. Я попробую и отчитаюсь. Спасибо!
@goldenapples Итак: Как дела?
@Кайзер Ха. Я отказался от попыток войти в систему Ajax, это казалось ненужным усложнением. Просто предоставил ссылку на страницу входа через HTTPS. Я думаю, мне следует попробовать еще несколько предложений здесь, чтобы я мог хотя бы принять ответ здесь для других людей. Вернёмся к этому.
@goldenapples Вы пробовали мое решение здесь? Пользуюсь много лет без проблем…
Извините, я знаю, что этот вопрос немного выходит за рамки этого сайта… но именно поэтому я наградил его. И я не зацикливаюсь на использовании какого-либо конкретного плагина, просто из всех плагинов входа в систему Ajax, которые я смотрел, этот оказался наиболее развитым и должен был потребовать наименьшей работы, чтобы добраться туда, где он мне нужен. Вот некоторые детали:
Действие формы задается site_url(‘wp-login.php’, ‘login_post’), а отправка Ajax извлекается из действия формы после вызова event.preventDefault(); Таким образом, оба они указывают на URL-адреса https, когда FORCE_SSL_ADMIN включен. Таким образом, URL-адрес действия формы не является проблемой.
Мм… В таком случае ваш подход к кадру, вероятно, правильный. Я предполагаю, что вы сталкиваетесь с проблемами, связанными с моделью безопасности браузера, также известной как WP, которая пытается установить безопасный файл cookie в незащищенном домене, другими словами, файл cookie на странице с другой схемой/доменом (не указать путь, поскольку он устанавливается для wp-admin).
Кстати, пробовали ли вы играться с доменами cookie и определяет путь к файлу cookie администратора (см. файл wp-settings.php)? Если проблема связана с моделью безопасности браузера, это может помочь, заставив их всех перейти к корневому пути сайта. (По очевидной цене в безопасности.)
Есть способы сделать это; вот так например. Я предполагаю, что Login With Ajax не использует все методы, описанные в этой статье, и некоторые функции безопасности браузера блокируют его. Попробуйте связаться с разработчиком и предложить улучшения, указав на эту статью.
Разница WordPress для hhtp и https и когда вы вызываете AJAX с функциями WP по умолчанию, возможна форма регистрации AJAX. Возможно, вы видите форму плагина из этого руководства: http://www.wpajax.com/code/ Я думаю, что это решение для вас.
У меня была аналогичная проблема, и оказалось, что все зависит от того, как
wp_signon( $credentials, $secure_cookie )была вызвана функция.Я хочу, чтобы все на моем сайте было https после входа в систему, поэтому незащищенный файл cookie бесполезен.
В моем коде до ssl было: wp_signon($credentials, false)
поэтому я изменил:
к
Что создает безопасный файл cookie, и теперь все в порядке.
Я могу представить, что разработчики плагинов пытаются
FORCE_SSL_ADMINустановить безопасный файл cookie, попробуйте использовать егоwp_signon( $credentials, false )в вашем случае. Я надеюсь, что это решит проблему.Не смотрел на плагин, но я предполагаю, что он жестко кодирует URL-адрес входа без https в запросе Ajax. Форма входа в wp отлично работает в своей версии без https вместе с действием формы, настроенным на использование https, поэтому я действительно не понимаю, почему Ajax не работает.
Если смена плагина невозможна, вы можете попробовать следующие подходы:
Можно было бы использовать jquery на хуке wp_footer. Найдите идентификатор формы входа и измените ее URL-адрес, например:
$(ID).attr('action', newValue);(Однако мне не 100, это сработает, поскольку я смутно припоминаю, как jquery кашлял на теги формы при изменении метода или действия формы.)
Второй подход, если URL-адрес появляется в HTML-коде формы входа, но не в ее вызове Ajax, состоит в том, чтобы запустить выходной буфер на
wp_headиstr_replace()URL-адрес.Третий подход, если фактический URL-адрес отображается в сценарии js в качестве параметра, заключается в переопределении его значения в wp_footer, как это делается в плагине auto-thickbox для URL-адресов изображений, используемых в wp.
Последний вариант, если сценарий представляет собой беспорядочный спагетти-код с URL-адресом входа, жестко закодированным в вызовах функций, — удалить его из очереди с помощью
wp_dequeue_script()и поставить в очередь свою собственную версию для его замены. Помните о приоритетах, если вы делаете это: вашеwp_print_scriptsдействие, очевидно, должно происходить после действия плагина.У меня была аналогичная проблема с плагином AJAX.
После предложения на https://stackoverflow.com/questions/6301076/wordpress-single-page-ssl добавил это в файл wp-config.php:
Затем я заставил конкретную страницу (с помощью AJAX) быть только https:// (для этого есть плагины).