Если бы я вошел в систему на моем сайте, сохраняя свой идентификатор $_SESSION, и из своего браузера он нажал кнопку «Сохранить», которая отправила бы запрос AJAX на сервер. Будут $_SESSIONли сохранены его и файлы cookie в этом запросе, и могу ли я смело полагаться на то, что идентификатор присутствует в $_SESSION?
Ответы:
Ответ да:
Сеансы поддерживаются на стороне сервера. Что касается сервера, то нет разницы между запросом AJAX и запросом обычной страницы. Оба они являются HTTP-запросами и содержат одинаковые данные cookie в заголовке.
Со стороны клиента одни и те же куки всегда будут отправляться на сервер, будь то обычный запрос или запрос AJAX. Код Javascript не должен делать ничего особенного или даже знать об этом, он просто работает так же, как и с обычными запросами.
Warning: session_write_close(): Failed to write session data (user)об ошибке в проекте, но только когда происходит запрос AJAX во время загрузки остальной части страницы. Я использую базу данных MySQL для данных сеанса, и вполне возможно, что запрос главной страницы блокирует эту таблицу, предотвращая доступ к ней запроса AJAX.
Если PHP-файл, содержащийся в AJAX-запросах, session_start()будет содержать информацию о сеансе. (за исключением запросов в пределах одного домена)
На самом деле вы получаете: отправляются ли файлы cookie с запросом AJAX? Предполагая, что запрос AJAX направлен на тот же домен (или в пределах ограничений файла cookie), ответ - да. Таким образом, AJAX-запросы обратно на тот же сервер сохраняют ту же информацию о сеансе (при условии, что вызываемые скрипты выдают session_start (), как и любой другой скрипт PHP, требующий доступа к информации сеанса).
Ну не всегда. Используя куки, вы хороши. Но «могу ли я смело полагаться на наличие идентификатора», побудило меня расширить обсуждение важным моментом (в основном для справки, так как количество посетителей этой страницы кажется довольно высоким).
PHP может быть настроен для поддержки сессий путем перезаписи URL, а не куки. ( Насколько это хорошо или плохо (<- см., Например, самый верхний комментарий там) - это отдельный вопрос , давайте теперь остановимся на текущем, только с одним дополнительным замечанием: самая заметная проблема с сеансами на основе URL - явный видимость голого идентификатора сеанса - не проблема с внутренними вызовами Ajax, но затем, если он включен для Ajax, он включается и для остальной части сайта, так что там ...)
В случае сеансов перезаписи URL (без файлов cookie) Ajax-вызовы должны сами позаботиться о том, чтобы URL-адреса их запросов были правильно обработаны. (Или вы можете свернуть свое собственное решение. Вы можете даже прибегнуть к ведению сеансов на стороне клиента , в менее требовательных случаях.) Суть заключается в явной заботе, необходимой для обеспечения непрерывности сеанса, если не используются файлы cookie:
Если вызовы Ajax просто извлекают URL-адреса дословно из HTML (как получено из PHP), это должно быть в порядке, так как они уже приготовлены (ммм, приготовлены).
Если им нужно собрать сами URI запроса, идентификатор сессии необходимо добавить в URL вручную. (Проверьте здесь , или источники страницы, сгенерированные PHP ( с перезаписью URL ), чтобы увидеть, как это сделать.)
С OWASP.org :
По сути, веб-приложение может использовать оба механизма, файлы cookie или параметры URL-адреса или даже переключаться с одного на другой (автоматическая перезапись URL-адреса), если выполняются определенные условия (например, наличие веб-клиентов без поддержки файлов cookie или когда файлы cookie не поддерживаются). принято из-за проблем конфиденциальности пользователя).
Из сообщения на форуме Ruby :
При использовании php с cookie-файлами идентификатор сеанса автоматически отправляется в заголовках запросов даже для Ajax XMLHttpRequests. Если вы используете или разрешаете сеансы php на основе URL, вам нужно будет добавлять идентификатор сеанса в каждый URL-адрес Ajax-запроса.
Очень важно, чтобы запросы AJAX сохранили сессию. Самый простой пример - когда вы пытаетесь сделать AJAX-запрос для панели администратора, скажем так. Конечно, вы будете защищать страницу, к которой вы делаете запрос, и недоступны для тех, у кого нет сеанса, который вы получаете после входа в систему администратора. Имеет смысл?
Однако следует обратить внимание на одну вещь, особенно если вы используете платформу, чтобы проверить, генерирует ли приложение идентификаторы сеанса между запросами - все, что явно зависит от идентификатора сеанса, будет иметь проблемы, хотя очевидно, что остальные данные в сеанс будет без изменений.
Если приложение регенерирует идентификаторы сессий, подобные этому, вы можете столкнуться с ситуацией, когда запрос ajax фактически делает недействительным / заменяет идентификатор сеанса на запрашивающей странице.
поместите ваш session () auth на все серверные страницы, принимающие ajax-запрос:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwiseэто единственный способ, которым я когда-либо делал это.
HttpOnlyфлаг при установке cookie, что означает, что ваш Javascript не сможет увидеть cookie. Однако cookie все равно будет отправляться как для AJAX, так и для обычных запросов страниц, и будет продолжать работать точно так же. Ваш Javascript просто не увидит егоdocument.cookie.