Вход в сеанс PHP после переключения на SSL

Я решил потратить несколько часов на попытки защитить свой сайт с помощью SSL. Сервер работает нормально, но мой PHP $_SESSION столкнулся с проблемой. Я понимаю проблему передачи идентификаторов сеанса между HTTP и HTTPS, но здесь этого не происходит (я думаю). Запутанная последовательность сеансов выглядит примерно так:

логин.html:

<form action="https://www.mydomain.com/login.php">

логин.php:

if login details correct {
   session_set_cookie_params(3600,'/','mydomain.com',true);
   session_start();
   $_SESSION['...
   session_commmit

На этом этапе login.js (который управляет диалоговым окном в стиле AJAX) будет перенаправлять на http://www.mydomain.com/desktop.html. Код JS, поддерживающий HTML, затем срабатывает

$.ajax({ url: "https://www.mydomain.com/lib/mySQL/mySQL.php", ... });

mySQL.php:

if (!isset($_COOKIE['PHPSESSID'])) {
   throw wobbly

До того, как я перешел на HTTPS, эта последовательность отлично работала во всех браузерах; с HTTPS он шатается во всех браузерах :( Я могу подтвердить (посмотрев на данные cookie), что Firefox записывает cookie следующим образом:

mydomain.com
Name: PHPSESSID
Content: gobbledygook
Domain: .mydomain.com
Path: /
Send For: Encrypyed connections only.
Expires:  in 1hr.

Все выглядит как в книге. Есть ли у вас какие-либо предложения относительно того, что происходит?

Спасибо.

PS: я не использовал session_set_cookie_params до того, как наткнулся на сообщение на SO при исследовании этой проблемы, предполагая, что мне следует это сделать. То есть до того, как я установил secure=true, Firefox «отправлял» любые подключения, и это тоже не сработало.

РЕДАКТИРОВАТЬ: я наблюдаю еще одну деталь. Я ожидаю, что на панели «Сеть» в Firebug мои запросы AJAX будут отображаться как «POST https://www.mydomain.com/lib/mySQL/mySQL.php", и я смогу выбрать райдер POST и посмотреть, что получилось. Я не понимаю этого для неудачного запроса. Как ни странно, Firebug отображает «ВАРИАНТЫ https://www.mydomain.com/lib/mySQL/mySQL.php" красным цветом и без POST-райдера.


javascript ssl php https
person Ollie2893    schedule 28.08.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Этот заголовок OPTIONS отправляется в качестве проверки, разрешены ли Межсайтовые HTTP-запросы.

https и http — это разные сайты, на которые распространяется Политика единого происхождения. По ссылке выше все понятно.

И еще одна статья о кросс-сайтовом XMLHTTPRequest (кеш Google)

person Lekensteyn    schedule 28.08.2010
comment
Спасибо. Я прочитал SOP после повторного чтения документов jQuery. Я также столкнулся с концепцией document.domain. Что бы я ни назначал, я всегда получал ошибку x-domain в разрешении на отказ в Firebug. Я не получаю эту ошибку, когда не работаю с document.domain. Это странно. Сообщение об ошибке, о котором сообщает Firebug (также красное) в строке OPTIONS IS MY OWN MESSAGE (т.е. нечеткое). То есть мой PHP-скрипт запустился. Однако обычно мой шаткий ответ возвращается через заголовок ответа. Кажется, здесь это не подходит. Судя по тому немногому, что я вижу в рукопожатии, действительно кажется, что я не отправляю куки. - person Ollie2893; 28.08.2010
comment
Таким образом, может показаться, что мой доступ AJAX предоставлен, но файлы cookie подавлены. Это немного попахивает httpOnly, но я попытался явно установить значение False - без радости. Чего я не могу понять, так это того, что этот файл cookie сеанса на самом деле ПРОИСХОДИТ в том же домене HTTPS, на который я пытаюсь его вернуть. Возможно, его не следует отправлять в домен HTTP. На самом деле, я пытаюсь сказать то же самое, устанавливая secure=true. - person Ollie2893; 28.08.2010
comment
Просто прочитайте вашу 1-ю ссылку, и это меня беспокоит. FF3.5 не так уж устарел, поэтому многие старые браузеры не будут поддерживать никаких попыток очистить мой запрос на доступ. Тогда способ обойти это может состоять в том, чтобы отказаться от файлов cookie сеанса и переключиться на передачу идентификатора сеанса через код? Меня никогда не устраивало, что мои идентификаторы сеансов на сегодняшний день пережили один сеанс благодаря куки. Может убить двух зайцев одним выстрелом? - person Ollie2893; 29.08.2010
comment
... который также не работает, потому что где-то при передаче от https:login.php к http:desktop.html (или, возможно, .php) идентификатор сеанса должен быть закодирован в URL-адресе и быть незашифрованным - a серьезный недостаток безопасности. - person Ollie2893; 29.08.2010

arrow_upward
0
arrow_downward

Хорошо, Лекенштейн направил меня в правильном направлении, хотя его ссылки более фаталистичны — с точки зрения программиста на стороне клиента — чем нужно: в мире AJAX ответом на эту конкретную загадку является аббревиатура JSONP. И если вы окажетесь в том же рассоле, то вот тривиальное решение jQuery:

В вашем вызове $.ajax: -

(1)  Set "dataType" to "jsonp"
(2)  Set "type" to "GET".  (The rest of my app is defaulted to POST.  The jQuery code  suggests that POST is supported.  But when I try POST, I get another "Permission denied" from Firefox' OPTIONS header.)
(3)  Where my PHP script would formerly reply

        echo json_encode($data);

     it must now go

        echo $_REQUEST['callback'].'('.json_encode($data).')'

     which effectively formats a function call with $data being the one and only parameter to the function.
(4)  Set "url" to "https://www.mydomain.com/lib/mySQL/mySQL.php"

Работает удовольствие. Формат GET немного уродлив, но эй-хо. Я оставил файл cookie PHPSESSID со значением «secure=true», поэтому он должен передаваться только через зашифрованные рукопожатия.

PS: Apols за ужасное форматирование. Однажды я обязательно выясню, как лучше форматировать свои сообщения на этом форуме.

person Ollie2893    schedule 29.08.2010