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


154

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

Ответы:


191

Ответ да:

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

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


10
Продолжение: сервер может установить HttpOnlyфлаг при установке cookie, что означает, что ваш Javascript не сможет увидеть cookie. Однако cookie все равно будет отправляться как для AJAX, так и для обычных запросов страниц, и будет продолжать работать точно так же. Ваш Javascript просто не увидит его document.cookie.
Томасруттер

Если включен отчет об ошибках PHP, вы можете получить сообщение об ошибке сеанса с ответом AJAX. В последнее время я периодически получаю сообщение Warning: session_write_close(): Failed to write session data (user)об ошибке в проекте, но только когда происходит запрос AJAX во время загрузки остальной части страницы. Я использую базу данных MySQL для данных сеанса, и вполне возможно, что запрос главной страницы блокирует эту таблицу, предотвращая доступ к ней запроса AJAX.
Buttle

@ButtleButkus, что звучит как проблема в вашем коде на стороне сервера, и я уверен, что люди будут готовы помочь, если вы отправите это как собственный вопрос. Вы не должны получать эту ошибку только потому, что вы используете MySQL для сессий, поскольку он не должен блокироваться таким образом, чтобы это могло привести к ошибке. Это может быть проблема с насыщением соединений MySQL, или какая-то другая не связанная с этим проблема.
Томасруттер

Это происходит на бродячем компьютере, поэтому соединения MySQL должны быть насыщенными. Я обязательно напишу вопрос, если не смогу это выяснить в ближайшее время.
Баттл Буткус

23

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


2
действительно, это то, что я забыл сделать :-)
sivann

23

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


1
Возможно, я ошибаюсь, но я думал, что даже публиковать запросы ajax на другие домены невозможно (исключая субдомены)?
Эмиль Х

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

1
Да, ajax-запросы не могут быть отправлены в другие домены. Тем не менее, вы можете динамически вставить тег <script> на страницу и установить для его src URL-адрес вне домена, который повторяет javascript.
Нажмите Upvote

1
Запросы ajax не могут быть сделаны в другие домены. но вы можете сделать прокси в своем PHP-коде. запрос ajax к прокси, запрос прокси к другому домену.
Питер Лонг

2
Только примечание ... ajax-запросы могут быть сделаны междоменными, но только если тип ответа - jsonp. Я все время это делаю.
Крещение

8

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

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

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

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

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


С OWASP.org :

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

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

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


Любая достоверная статистика о том, у скольких людей отключены сеансовые куки (Я не смог найти ни только на Javascript: что , кажется , около 2% в США / Европе и ~ 1,2% мирового Avg..)
Sz.

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

3

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


0

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

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


0

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


0

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

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

//run json code

}

// do nothing otherwise

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.