сеанс — PHP сервер отправляет куки, браузер получает их, но куки не найдены
Я искал и искал, но, кажется, ничто не соответствует моей проблеме.
В моей среде разработки у меня есть несколько PHP-скриптов для генерации HTML-кода для клиента. Я создал свой собственный менеджер сессий, и все в моем коде работает (пока), пока я не попытаюсь отправить куки на новый сеанс. Вот некоторый код, чтобы дать идею:
<?php
class Session {
private $data = null;
private $id = null;
private $token = null;
private $access = null;
private $oldID = null;
private static $ck_limit = 180;
private static $ck_domain = "kiosk.local.com";
...
public function __construct() {
setcookie("id", $this->id, (time() + self::$ck_limit), '/', self::$ck_domain, true, true);
}
?>
По Firebug браузер получает куки очень хорошо, но в списке куки нигде его нет! Обновления страниц ничего не делают, и кажется, что никакие куки не попадают в хранилище клиента. Ссылки являются абсолютными путями, по HTTPS, сертификаты постоянно хранятся и являются доверенными, а изменение любого из этих параметров не приводит к cookie.
Я тестировал прием куки с гуглом в том же браузере, и они работают.
На всякий случай, если кто-то спросит, имя хоста моей машины — это полное доменное имя kiosk.local.com, и файл моего хоста сопоставлен с его интерфейсами. Это не мой первый сервер, но я впервые имею дело с файлами cookie в PHP.
Я гарантировал, что есть НИЧЕГО ТАКОГО перед отправкой клиенту перед отправкой файла cookie, и я попытался отправить его без каких-либо данных, с пустой страницей и страницей, которую я регулярно отправляю, и попытался без буферизации вывода.
Есть ли причина, по которой это должно происходить? Мой error.log для apache ничего не говорит о cookie, и метод PHP setcookie () возвращает true, а Firebug не сообщает об ошибках при загрузке страницы … просто нет cookie в списке файлов cookie. Я вижу данные cookie в полученном заголовке, но это единственный признак того, что сервер выполняет свою работу.
Браузером является Firefox 40.0.3 для Ubuntu 12.04.3 LTS, расширениями являются Firebug, FireQuery, Firefox HTTP-аутентификация из подресурсов Исправление и Ubuntu Модификации.
Решение
Я думаю, что нашел свой ответ сегодня утром на догадку. Код сервера в порядке. Что я случайно упустил из виду, потому что я не думал, что это оказало какое-либо влияние или влияние на систему, так это то, что клиент и хост — это одна и та же машина, что означает, что я запускаю браузер от пользователя на машине, на которой находится сервер apache2. бежит из. Мой проект здесь представляет собой отдельное приложение, основанное на Интернете с использованием PHP и MySQL. Я трижды проверил, что браузер действительно запрашивает правильный URL-адрес (я отправил тот же URL-адрес моему внешнему клиенту, так что это не тривиальная ошибка с этой стороны).
Я полагаю, что проблема в том, что каким-то образом, если браузер или сервер apache2 определит, что cookie будет отправлен клиенту с тем же именем, что и сервер, cookie будет съеден по мере его поступления. Не уверен, какая служба использует cookie, но ясно, что Firefox сообщает о получении cookie после его отправки, поэтому либо Apache его ест, либо Firefox.
Независимо от того, кто является виновником, для меня ясно, что куки не могут быть использованы на сервере / клиенте, которые имеют тот же хост / IP, по крайней мере, когда они Apache2.2.22 и Firefox 40.0.3, даже при использовании FQDN.
Итак, короче говоря, автономные приложения для клиентов на их собственном сервере (головоломка) не могут использовать файлы cookie от себя.
Если у кого-то есть другая причина, по которой это происходит, и приемлемый обходной путь, который НЕ включает обход мер безопасности или иным образом ставит под угрозу безопасность приложения, веб-содержимого, сети или использования прокси-сервера, я открыт для него. Я не говорю прокси, потому что эта программа является автономной в качестве киоска, за исключением доступа администратора через точку доступа Wi-Fi, которую создает хост-устройство (без маршрутизаторов). Есть причины для этого, которые не будут обсуждаться, просто примите тот факт, что эта настройка не изменится, и что приняты все меры предосторожности для обеспечения надлежащей безопасности для этой конкретной установки.
Очевидно, что если файлы cookie нельзя использовать на том же хосте, который их отправляет, у меня может не быть другого выбора, кроме как представить другое устройство в качестве клиента, которое мне нужно будет обсудить с менеджером проекта, прежде чем это будет сделано. Нет, о виртуальной машине не может быть и речи, поскольку технические характеристики оборудования на сервере недостаточно высоки для запуска виртуальной машины и хоста, плюс я не думаю, что сочетание архитектуры / платформы поддерживается как хост виртуальной машины.
::РЕДАКТИРОВАТЬ::
Я выяснил виновника и исправил проблему. Пожалуйста, извините меня за одно мгновение, пока я бью себя по этому поводу, даже если это происходит …
* SLAP *
Итак, вот что в итоге стало разницей между двумя браузерами:
Браузер моей Хост-машины (для виртуальной машины, на которой работает dev-сервер) настроен на то, что я обычно использую, для запоминания истории, для принятия файлов cookie при нормальных обстоятельствах, бла, бла, бла. Однако из-за того, что я хотел, чтобы среда разработки максимально эмулировала производственную среду для реальной обратной связи, я настроил браузер так, чтобы он никогда не запоминал историю и не принимал файлы cookie, кроме как из домена киоска. По-видимому, несмотря на то, что сайт находится в списке исключений, и даже если разрешено принимать все файлы cookie, частный просмотр удаляет все файлы cookie, которые появляются в заголовках, и не сообщает о том, что они были отклонены по любой причине. Так что не было возможности увидеть Зачем куки не появлялись после того, как браузер их получил. Хотя есть странный момент, мой внешний хост Firefox Browser по-прежнему получает куки даже при приватном просмотре … странно, что он может это сделать, но внутренний клиент не может …
Итак, после изменения настроек Firefox внутреннего хоста на обычный просмотр, но удаления всех данных о просмотре в браузере, эта проблема решена. Это имеет тот же конечный результат, за исключением данных является запись на диск в тех случаях, когда нам вообще не нужны данные, но в конце дня все удаляется, что не составляет особого труда.
Итак, я скажу, что Firefox 40.0.3 для Ubuntu x86_64 имеет ошибку, заключающуюся в том, что когда на вкладке «Конфиденциальность» в настройках используется «всегда использовать частный режим просмотра», никакие куки не пройдут через прием заголовка, если они были получены из его собственного лицо сервера. Вам придется использовать обходной путь, который удаляет данные о вашем браузере при закрытии браузера, и обязательно регулярно закрывайте браузер. Проблема сейчас решена.
Другие решения
Других решений пока нет …