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

Question

Если бы я вошел в систему на моем сайте, сохраняя свой идентификатор в $_SESSION, и из своего браузера он нажал кнопку «Сохранить», которая отправила бы запрос AJAX на сервер. Будут ли его $_SESSION и файлы cookie сохраняться в этом запросе, и могу ли я смело полагаться на идентификатор, присутствующий в $_SESSION?

Answer 1

Ответ - да:

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

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

Answer 2

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

Answer 3

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

Answer 4

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

PHP может быть настроен для поддержки сессий путем переписывания URL-адресов вместо файлов cookie. ( Насколько это хорошо или плохо (<- см., Например, самый верхний комментарий там) - это <a href="https://stackoverflow.com/questions/5944757/url-rewriting-does-that-cause-a-security-issue"> отдельный вопрос , давайте теперь придерживаться текущего, только с одной боковой примечание: наиболее заметная проблема с сеансами на основе URL - явная видимость голого идентификатора сеанса - это не проблема с внутренними вызовами Ajax, но затем, если он включен для Ajax, он включается для остальных сайт тоже так есть ...)

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

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

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

---

С OWASP.org :

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

Из Ruby-форума сообщение:

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

Answer 5

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

Answer 6

поместите ваш сеанс () авторизации на всех серверных страницах, принимающих ajax-запрос:

if(require_once("auth.php")) {

//run json code

}

// do nothing otherwise

это единственный способ, которым я когда-либо делал это.

Answer 7

Это то, что делают фреймворки, например если вы инициализируете сессию в Front Controller или скрипт Boostrap, вам не придется заботиться об его инициализации ни для контроллеров страниц, ни для контроллеров ajax. Фреймворки PHP не являются панацеей, но они делают так много полезных вещей!

Answer 8

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

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