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