Запросы AJAX сохраняют информацию о сеансе PHP?

Ответ 1

Ответ:

Сессии поддерживаются на стороне сервера. Что касается сервера, то нет разницы между запросом AJAX и регулярным запросом страницы. Они оба являются HTTP-запросами, и оба они содержат информацию cookie в заголовке тем же способом.

С клиентской стороны те же файлы cookie всегда будут отправляться на сервер, независимо от того, является ли он обычным запросом или запросом AJAX. Код Javascript не должен делать ничего особенного или даже знать об этом, он просто работает так же, как и с обычными запросами.

Ответ 2

То, что вы действительно получаете, это: отправляются файлы cookie с запросом AJAX? Предполагая, что запрос AJAX относится к одному и тому же домену (или к ограничениям домена для файла cookie), ответ да. Поэтому запросы AJAX на один и тот же сервер сохраняют одну и ту же информацию о сеансе (при условии, что вызываемые скрипты выдают session_start(), как любой другой PHP script, желающий получить доступ к информации о сеансе).

Ответ 3

Если файл PHP для запросов AJAX имеет session_start(), информация о сеансе будет сохранена. (запрет запросов находится в пределах одного домена)

Ответ 4

Ну, не всегда. Используя файлы cookie, вы хороши. Но "могу ли я безопасно полагаться на присутствующий идентификатор" призвал меня расширить обсуждение с важным моментом (в основном для справки, так как количество посетителей этой страницы кажется довольно высоким).

PHP может быть настроен на сохранение сеансов путем перезаписи URL вместо файлов cookie. (Как это хорошо или плохо (< - см. например, самый верхний комментарий там) является отдельный вопрос, давайте теперь придерживаться текущего, только с одной стороны: самая важная проблема с сеансами на основе URL-адресов - вопиющая видимость голого идентификатора сеанса - не проблема с внутренним Ajax но затем, если он включен для Ajax, он включается и для остальной части сайта, поэтому там...)

В случае сеансов перезаписи URL (cookieless), вызовы Ajax должны сами позаботиться о себе, чтобы их URL-адреса запросов были правильно обработаны. (Или вы можете свернуть свое собственное решение. Вы даже можете прибегнуть к обслуживанию сеансов на стороне клиента, в менее сложных случаях.) Точка является явной заботой, необходимой для непрерывности сеанса, если не используется куки:

• Если Ajax вызывает только извлечение URL-адресов из HTML (как получено из PHP), это должно быть ОК, поскольку они уже приготовлены (umm, cookified).

• Если им необходимо собрать собственные URI-запросы, идентификатор сеанса должен быть добавлен в URL-адрес вручную. (Проверьте здесь или источники страниц, сгенерированные PHP (с URL-адресом -rewriting на), чтобы увидеть, как это сделать.)

От OWASP.org:

Эффективно веб-приложение может использовать оба механизма, файлы cookie или URL-адреса или даже переключаться с одного на другой (автоматический URL-адрес переписывание), если выполняются определенные условия (например, существование веб-клиентов без поддержки cookies или когда файлы cookie не принятые в связи с проблемами конфиденциальности пользователей).

Из Ruby-forum сообщение:

При использовании php с кукисами идентификатор сеанса будет автоматически отправляться в заголовках запроса даже для Ajax XMLHttpRequests. Если вы использовать или разрешать php-сессии на основе URL-адресов, вам нужно будет добавить идентификатор сеанса к каждому URL-адресу запроса Ajax.

Ответ 5

Очень важно, чтобы AJAX-запросы сохраняли сеанс. Самый простой пример - когда вы пытаетесь выполнить запрос AJAX для панели администратора, скажем так. Конечно, вы будете защищать страницу, на которую вы отправляете запрос, а не на доступ к другим, у которых нет сеанса, который вы получаете после входа в систему администратора. Имеет смысл?

Ответ 6

Одна вещь, о которой нужно помнить, особенно если вы используете фреймворк, заключается в проверке того, восстанавливает ли приложение идентификаторы сеанса между запросами - все, что явно зависит от идентификатора сеанса, сталкивается с проблемами, хотя, очевидно, остальная часть данные в сеансе не будут затронуты.

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

Ответ 7

Что делают рамки, например. если вы инициализируете сеанс в Front Controller или boostrap script, вам не нужно будет заботиться об этом для инициализации либо для контроллеров страниц, либо для контроллеров ajax. Фреймворки PHP не являются панацеей, но они делают так много полезных вещей, как это!