Чи слід уникати змінних сеансів?

Раніше я сильно покладався на змінні сеансу, але останнім часом багато з них виявилися непотрібними, замість цього використовуючи такі речі, як параметри рядка запиту.

Мій колега відмовляється від використання змінних сесії. Це реальна мета і чи слід уникати змінних сеансів з будь-яких практичних причин? Чи можна повністю уникати змінних сеансів (за винятком сеансових файлів cookie для входу в систему) і це призведе до кращих конструкцій?

Деякі з причин того, що мій колега не використовує їх:

• Нетиповий характер змінних сеансу
• Тайм-аути сесії, що спричиняють втрату стану
• Характер глобальних змінних змінних сеансів
• Завантажити балансуючі сервери, що втрачають сеанси (.Net specific?)
• Перезапуск пулів / серверів додатків
• Вони непотрібні

Якщо у вашій програмі є змінна сесія, запитайте себе так:

Коли я натискаю кнопку "назад" у веб-переглядачі, яке значення я хочу, щоб моя змінна?

Якщо відповідь "поточне значення", можуть бути корисні змінні сеансу. Прикладом може бути кошик для покупок: ви не очікуєте, що речі будуть вилучені з кошика, коли ви повернетесь назад в історію. Це завжди в його нинішньому стані.

Якщо відповідь "попереднє значення", вам не слід використовувати змінні сеансу. Неправильне використання, яке я бачив, включає проходження параметра між сторінками. Якщо я натискаю кнопку "Назад", щоб повернутися до сторінки, вона не обов'язково отримує правильний параметр. Крім того, якщо я відкрию дві вкладки, як тоді поводиться мій сайт?

Правильне поведінку кнопки "назад" - це аж ніяк не все-таки і все-таки, але це допомагає вам думати про веб-сайт як про додаток без громадянства. Загалом, я вважаю, що відповідні можливості використання змінних сеансу є небагато і між ними.

Протокол HTTP не має статусу. Сеанси - це спосіб збереження стану клієнта для HTTP-запитів. Ви можете зробити це за допомогою вбудованої обробки сеансу на платформі або зробити це самостійно за допомогою параметрів рядка запиту. У будь-якому випадку деяка концепція сеансу необхідна для багатьох завдань.

Ваш колега, ймовірно, не любить конкретного виконання або не використовував сеанси за призначенням. Якщо вам потрібно зберегти інформацію про певне з'єднання з клієнтами через HTTP-запити, вам потрібна певна форма збереження сеансу.

Наступні питання стосуються конкретного впровадження:

Нетиповий характер змінних сеансу

Характер глобальних змінних змінних сеансів

Завантажте балансуючі сервери, що втрачають сеанси

Перезапуск пулів / серверів додатків

Наприклад, я найчастіше працюю в PHP і зберігаю інформацію про сеанси у реляційній базі даних. Тому мої змінні сеансу набираються. Балансування завантаження та перезавантаження сервера не викликають проблем із сеансом.

Цей цікавіший:

Тайм-аути сесії, що спричиняють втрату стану

Сесії найчастіше зберігаються за допомогою файлів cookie. Вони можуть бути видалені клієнтом у будь-який час. Але вони також можуть бути збережені за допомогою параметра рядка запиту і тому ніколи не вичерпуються на клієнта. Час очікування сервера залежить від вас. Тож навіть це питання є специфічним для впровадження.

Не будемо викидати всю концепцію сеансів тільки тому, що нам не подобається конкретна реалізація. Будь-яка хороша рамка веб-додатків полегшить правильне використання сеансів, щоб зберегти входи користувачів або зберегти все інше, що стосується поточного відвідування користувача. Запис бази даних користувача може (і повинен) використовуватися для зберігання специфічних для них речей під час входу. Однак, анонімні відвідувачі можуть мати тимчасову інформацію, яку також варто зберегти під час сеансу, наприклад, короткий список останніх відвідуваних сторінок або перевагу приховати повідомлення, яке вони вже бачили. Зазвичай для зберігання сеансу підходить лише менша тимчасова інформація.

Інші зробили багато хороших моментів (які я не буду повторювати), але є один аспект техніки вашого приятеля, про який ще не йшлося: безпека .

Неможливо дізнатися, які уразливості ви відкриваєте, не дивлячись на код, але ось декілька речей, які я можу придумати вгорі голови.

• Фіксація сеансу : Потужна атака, яка трохи легша, якщо ви можете просто навести на користувача посилання на посилання, яке вже містить необхідну інформацію в URL-адресі (а не намагатися змусити користувача використовувати машину, на якій належним чином встановлено файли cookie).
• Введення SQL (або інший шкідливий ввід) : ніколи не довіряйте нічого, що надходить від користувача. Змінні сесії мають перевагу ніколи не залишати сервер, тому користувач не може безпосередньо їх змінити. Хоча ви повинні санітувати дані, перш ніж вносити їх у сеанс, ви завжди можете довіряти цінностям, які ви отримаєте згодом. Якщо все передається навколо рядка запиту, у вас є багато перевірки, що вам потрібно зробити, щоб переконатися, що ви не приймаєте зловмисні дані.
• Пошкодження даних за допомогою фальсифікованих даних : Як і введення SQL, скільки даних ви передаєте вперед і назад? Наскільки це важливо? Чи можу я змінити поведінку вашого додатка, змінивши значення в рядку запиту? Чи можу я пошкодити дані на вашому сервері, змінивши значення? Якщо мені вдасться пошкодити дані на сервері, це вплине на інших користувачів? (Якщо ваша відповідь була "ні", моя відповідь - "ви впевнені? У вас є багато місць, які вам потрібно перевірити.").

Все це все ще може статися, коли ви використовуєте сеанси, але вони можуть стати набагато простішими, якщо ваш друг не знає, що він робить.

Змінні сесії певною мірою схожі на старі глобальні глобальні змінні. На користувачеві лежить тягар, щоб вони відстежували їх, що в них є, їх сферу застосування та як вони використовуються; так само, як у старих версіях BASIC. При цьому, чому хтось повністю знизить використання механізму, який очевидно розроблений як невід'ємна і дуже важлива частина моделі програмування (ASP, MVC тощо)?

Єдине погане, що я зіткнувся з використанням змінних Session - це те, що ви покладаєте на себе тягар, щоб ви їх слідкували, переконайтеся, що вони заповнені релевантними даними та розпоряджаються ними.

Хіба це не те, що ми робимо, коли програмуємо будь-який спосіб?

Я думав, як ваш колега через поганий досвід, у мене виникли проблеми налагодження, пов’язані зі змінними сеансів, які з мого боку були справді некомпетентними. Так, ви можете отримати певну міру без змінних сеансів, використовуючи рядки запитів, приховані поля у формах та інші речі. Однак це дуже швидко стає громіздким зробити це таким чином, якщо у вашій програмі є що-небудь, крім самого основного потоку логіки для визначення стану. Існує також ризик безпеки відображення внутрішніх функцій вашої програми за допомогою рядків запитів та прихованих полів, будь-яке з яких може слугувати векторами атаки.

Працюючи зі змінними сеансу, вам просто потрібно слідкувати за тим, коли вони встановлюються та скасовуються, оскільки це визначатиме логічний потік програми. Це як управління пам’яттю на такій мові, як C.

Зауважте, що це лише з мого досвіду роботи з PHP над відносно невеликим проектом без фреймворків, на інших платформах все може бути інакше, але я думаю, загальний принцип все ще діє.

Як було зазначено раніше, HTTP не має статусу без змін і сеанс. Дизайн HTTP без стану допомагає кешувати ресурси. Для загальнодоступних ресурсів.

Можна створити веб-сайт без змінної сесії, але це складніше. Найскладніше (IMHO) - фантастичне вхід / вихід, схеми аутентифікації HTTP не надають інструментів, необхідних для автентифікації за допомогою HTML-форми (ви можете зламати щось з javascript - XHR на https: // untel: passowrd@mydomain.com ) та ще складніше вийти з системи та бути сумісним для браузера. була певна дискусія щодо списків розсилки w3 з цього приводу, але якщо я правильно пам'ятаю, ідея відпала.

В іншому, ви повинні мати можливість жити без змінних Session. У вас буде деякий стан у базі даних, файлах чи будь-де, але використання змінних Session має бути рідкісним.

Якщо у вашого користувача є кошик для покупок, це змінний сеанс, лише якщо користувач має змогу переглядати на двох комп’ютерах / веб-переглядачах без спільного використання кошика.