Если бы я зарегистрировал пользователя на моем сайте, указав его идентификатор в $_SESSION , и из своего браузера он нажал кнопку «Сохранить», которая сделает запрос AJAX на сервер. Будут ли сохранены его $_SESSION и файлы cookie в этом запросе, и могу ли я уверенно полагаться на идентификатор, присутствующий в $_SESSION ?
Ответ:
Сессии поддерживаются на стороне сервера. Что касается сервера, то нет разницы между запросом AJAX и регулярным запросом страницы. Они оба являются HTTP-запросами, и оба они содержат информацию cookie в заголовке таким же образом.
С клиентской стороны одни и те же файлы cookie всегда будут отправляться на сервер независимо от того, является ли он обычным запросом или запросом AJAX. Код Javascript не должен делать ничего особенного или даже знать об этом, он просто работает так же, как и с обычными запросами.
То, что вы действительно получаете, это: отправляются файлы cookie с запросом AJAX? Предполагая, что запрос AJAX относится к одному и тому же домену (или к ограничениям домена для файла cookie), ответ да. Таким образом, AJAX обращается к тому же серверу, сохраняя ту же информацию о сеансе (при условии, что вызываемые сценарии выдают session_start () в соответствии с любым другим скриптом PHP, требующим доступа к информации о сеансе).
Если в файле PHP запросы AJAX имеют session_start() о сеансе будет сохранена. (запрет запросов находится в пределах одного домена)
Ну, не всегда. Используя файлы cookie, вы хороши. Но «могу ли я надежно полагаться на присутствующий идентификатор» призвал меня расширить дискуссию с важным моментом (в основном для справки, так как количество посетителей этой страницы кажется довольно высоким).
PHP может быть настроен для поддержки сеансов путем перезаписи URL вместо файлов cookie. ( Как это хорошо или плохо (<- см. Например, самый верхний комментарий там) – это отдельный вопрос , давайте теперь придерживаться текущего, только с одной стороны: самая важная проблема с сеансами на основе URL-адресов – вопиющая видимость идентификатора голого сеанса – это не проблема с внутренними вызовами Ajax, но затем, если он включен для Ajax, он также включен для остальной части сайта, так что …)
В случае сеансов перезаписи URL (cookieless), вызовы Ajax должны сами позаботиться о том, чтобы их URL-адреса запросов были правильно обработаны. (Или вы можете свернуть свое собственное решение. Вы даже можете прибегнуть к поддержке сеансов на стороне клиента , в менее сложных случаях.) Дело в том, что для обеспечения непрерывности сеанса требуется явная осторожность , если вы не используете файлы cookie:
Если Ajax вызывает только извлечение URL-адресов дословно из HTML (как получено из PHP), это должно быть ОК, поскольку они уже приготовлены (umm, cookified).
Если им нужно собрать собственные URI запроса, идентификатор сеанса должен быть добавлен в URL вручную. (Проверьте здесь или источники страниц, сгенерированные PHP ( с URL-переписыванием ), чтобы посмотреть, как это сделать.)
От OWASP.org :
Фактически веб-приложение может использовать оба механизма, файлы cookie или параметры URL-адреса или даже переключиться с одного на другое (автоматическое переписывание URL-адресов), если выполняются определенные условия (например, наличие веб-клиентов без поддержки файлов cookie или когда куки-файлы не являются принятые в связи с проблемами конфиденциальности пользователей).
Сообщение от Ruby-forum :
При использовании php с куки-файлами идентификатор сеанса будет автоматически отправляться в заголовках запросов даже для Ajax XMLHttpRequests. Если вы используете или разрешаете сеансы php на основе URL-адресов, вам придется добавить идентификатор сеанса на каждый URL-адрес запроса Ajax.
Очень важно, чтобы AJAX-запросы сохраняли сеанс. Самый простой пример – когда вы пытаетесь выполнить запрос AJAX для панели администратора, скажем так. Конечно, вы будете защищать страницу, на которую вы отправляете запрос, а не на доступ к другим, у которых нет сеанса, который вы получаете после входа в систему администратора. Имеет смысл?
Одна вещь, о которой нужно помнить, особенно если вы используете фреймворк, заключается в проверке того, восстанавливает ли приложение идентификаторы сеанса между запросами – все, что явно зависит от идентификатора сеанса, столкнутся с проблемами, хотя, очевидно, остальная часть данных в сессия не будет затронута.
Если приложение регенерирует идентификаторы сеанса, подобные этому, вы можете столкнуться с ситуацией, когда запрос ajax фактически аннулирует / заменяет идентификатор сеанса на запрашивающей странице.
Это то, что делают фреймворки, например, если вы инициализируете сеанс в Front Controller или скрипте boostrap, вам не придется заботиться о его инициализации либо для контроллеров страниц, либо для контроллеров ajax. Фреймворки PHP не являются панацеей, но они делают так много полезных вещей, как это!