Сохраняют ли запросы AJAX информацию о сеансе PHP?
Если бы у меня был пользователь, вошедший на мой сайт, его идентификатор хранится в $_SESSION, и из своего браузера он нажал кнопку "Сохранить", которая сделает запрос AJAX на сервер. Его $_SESSION и cookies будут сохранены в этом запросе, и я могу безопасно полагаться на id, присутствующий в $_SESSION?
7 ответов
да:
сеансы хранятся на стороне сервера. Что касается сервера, нет никакой разницы между AJAX-запросом и обычный запрос. Они оба являются HTTP-запросами, и оба они содержат информацию cookie в заголовке одинаково.
со стороны клиента на сервер всегда будут отправляться одни и те же файлы cookie, будь то обычный запрос или запрос AJAX. Код Javascript не должен делать ничего особенного или даже чтобы знать об этом, он просто работает так же, как и с регулярными запросами.
то, что вы действительно получаете: отправляются ли куки-файлы с запросом AJAX? Предполагая, что запрос AJAX относится к тому же домену (или в пределах ограничений домена cookie), ответ да. Таким образом, запросы AJAX обратно на тот же сервер сохраняют ту же информацию о сеансе (предполагая, что вызываемые скрипты выдают session_start() согласно любому другому скрипту PHP, желающему получить доступ к информации о сеансе).
Если PHP-файл AJAX-запросов имеет session_start() информация о сеансе будет сохранена. (baring запросы находятся в одном домене)
Ну, не всегда. Используя cookies, Вы хороши. Но ... --3--> "могу ли я безопасно полагаться на ID, присутствующий" призвал меня расширить обсуждение важным моментом (в основном для справки, поскольку количество посетителей этой страницы кажется довольно высоким).
PHP может быть настроен для обслуживания сеансов путем перезаписи URL-адресов, а не файлов cookie. (как это хорошо или плохо (отдельным вопрос, давайте теперь придерживаться текущего, только с одной стороны-Примечание: самая заметная проблема с сеансами на основе URL-адресов-вопиющая видимость голого идентификатора сеанса-это не проблема с внутренними вызовами Ajax; но тогда, если он включен для Ajax, он включен и для остальной части сайта, так что там...)
в случае сеансов перезаписи URL-адресов (cookieless) вызовы Ajax должны позаботиться об этом сами что их URL-адреса запросов правильно созданы. (Или вы можете свернуть свое собственное решение. Вы даже можете прибегнуть к поддержанию сессий на стороне клиента, в менее сложных случаях.) В комнату меры предосторожности необходимо для непрерывности сеанса, если не использовать cookies:
Если Ajax вызывает просто экстракт URLs дословно из HTML (как получено из PHP), это должно быть в порядке, так как они уже приготовлены (umm, cookified).
Если им нужно собрать запрашивают сами URIs, идентификатор сеанса должен быть добавлен к URL вручную. (Проверка здесь, или источники страниц, созданные PHP (С URL-переписыванием на), чтобы увидеть, как это сделать.)
от OWASP.org:
эффективно, веб-приложение может использовать оба механизма, печенье или Параметры URL или даже переключение с одного на другой (автоматический URL переписывание) при соблюдении определенных условий (например, наличие веб-клиентов без поддержки cookies или когда cookies не принято из-за соображений конфиденциальности пользователя).
с Рубин-форума сообщение:
при использовании php с cookies идентификатор сеанса будет автоматически отправлен в заголовках запросов даже для Ajax XMLHttpRequests. Если вы используйте или разрешите сеансы php на основе URL, вам нужно будет добавить идентификатор сеанса на каждый url-адрес запроса Ajax.
очень важно, чтобы запросы AJAX сохраняли сеанс. Самый простой пример - когда вы пытаетесь сделать запрос AJAX для панели администратора, скажем. Конечно, вы защитите страницу, на которую вы делаете запрос, а не доступную другим, у кого нет сеанса, который вы получаете после входа администратора. Смысл?
одна вещь, которую нужно остерегаться, хотя, особенно если вы используете фреймворк, - это проверить, восстанавливает ли приложение идентификаторы сеанса между запросами-все, что явно зависит от идентификатора сеанса, столкнется с проблемами, хотя, очевидно, остальные данные в сеансе не будут затронуты.
Если приложение восстанавливает идентификаторы сеанса, как это, то вы можете в конечном итоге с ситуацией, когда запрос ajax фактически аннулирует / заменяет идентификатор сеанса в запрашиваемая страница.
Это то, что делают фреймворки, например, если вы инициализируете сеанс в Front Controller или Boostrap script, вам не придется заботиться о его инициализации для контроллеров страниц или контроллеров ajax. PHP фреймворки не панацея, но они делают так много полезных вещей, как это!