Я знаю, що це великий шанс бути позначеним як дублікат, але я не зміг знайти саме те, що шукаю

Це поширена проблема, і я впевнений, що вона має чітко визначене найкраще рішення

Фон

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

2. Сеанс сервера містить лише об’єкт користувача, використовуючи непостійний cookie сеансу

3. Сесія закінчується на сервері через X годин

4. Деякі речі завантажуються лише під час входу

Проблема

1. Користувач працює над програмою, після завершення роботи користувач не виходить із системи, а залишає браузер відкритим
2. Користувач повертається через більш ніж X години (сеанс недійсний на сервері)
3. Користувач взаємодіє з додатком, не потребуючи підключення до сервера (перетягує речі, редагує текст ...)
4. Тільки при наступній взаємодії з сервером (припустимо, немає автоматичного збереження) користувач перекидається на сторінку входу і втрачає частину своєї роботи

Можливі рішення

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

1. Ніколи не виходити з користувача

• Як? або продовжуйте тривалий сеанс, зберігайте стійкий файл cookie або ping-javaScript "підтримуйте життя"
• Плюси : користувачеві не потрібно нічого турбуватися, виправляє проблему
• Мінуси : не сумісні з PCI, не захищені і не потребують змін у розробці, наприклад, речі, завантажені до сеансу лише у користувальницькому вході, потрібно перейти до під-моделі паб (прослуховування змін подій) або мати тайм-аут кешу.

2. Місцеве зберігання

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

3. Автозбереження

Кожна дія користувача, яка змінює модель, повинна зберігатися негайно (або через якусь чергову сторону клієнта), наприклад, якщо вони перевіряють прапорець, змінюють текстове поле або щось перетягують, як тільки вони будуть виконані, збережуть зміни.

• Як? Використовуйте рамку MV ** (Backbone.js / Knockout.js / Ember.js / Angular.js тощо), щоб прив'язати модель та наполягати на змінах.
• Плюси : здається, чисте рішення, сеанс активний доти, доки користувач активний, жодна робота клієнта не виконується без наполегливості.
• Мінуси : Останній користувач робить після втрати часу сеансу.

4. Вийдіть із користувача після закінчення сеансу

це може мати кілька підходів

1. Запитайте у сервера "термін дії сесії закінчився" - це дещо спіймана кішка 22 / Schrodinger's cat, оскільки просте запитання до сервера продовжує сеанс (перезапускає тайм-аут),

   • Як? У вас може бути сервер, який підтримує таке питання (я не знаю жодного, але я прийшов із Java land), або можна просто зберегти таблицю ідентифікаторів сеансу та час останнього доступу вручну та запитати сервер, пройшовши сеанс Ідентифікатор як параметр замість файлу cookie, я не впевнений, чи це можливо, але це звучить небезпечно, невпевнено і поганий дизайн сторінки whatsoever.login, зберігається після входу в систему
   • Плюси : Якщо на серверах була така підтримка, це звучить як чистий законний запитання (запитання, чи є у користувача X ще сеанс чи ні, не поновлюючи його, якщо він є)
   • Мінуси : Якщо сервер не підтримує його (і знову ж таки, я не знаю, чи має якийсь сервер або фреймворк цю функціональність), тоді вирішення може мати величезні ризики для безпеки.

2. Я чув, що я вирішував це короткий сеанс на стороні сервера і невідкладний пінг на стороні клієнта, який містить максимальну кількість пінгів

   • Як? Короткий сеанс на сервері, клієнт проводить кожну сесіюTimeOut / 2, має максимум спроб Y.
   • Плюси : вигляд виправляє проблему, швидко та брудно
   • Мінуси : Ви відчуваєте себе злому, обробляючи оновлення сесії самостійно, а не дозволяючи серверу це робити

3. Таймер на стороні клієнта

   • Як? Майте таймер на стороні клієнта та синхронізуйте його із сервером, перезавантаживши його під час кожного запиту, щоб він дорівнював максимальному тайм-ауту сеансу на сервері за вирахуванням деякої прокладки, після того як користувач не надсилає жодний запит на сервер, користувальницький інтерфейс показує "сеанси Ви хочете продовжити? " (як у вас в Інтернеті)

   • Плюси : виправляє проблему

   • Мінуси : Не можу придумати жодного, крім необхідності переконатися, що синхронізація працює

Питання

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

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

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

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

Я чув, що я вирішував це короткий сеанс на стороні сервера та пінг збереження> живий клієнт, який має максимальну кількість

Як? Короткий сеанс на сервері, клієнт проводить кожну сесіюTime / 2, має max> повторень Y. Плюси: Вид виправляє проблему, швидкий і брудний Мінуси: Похоже на злом, самостійно обробляючи оновлення сесії, а не> дозволяючи серверу робити це

Це, на мій погляд, найкраще рішення. Чому ви вважаєте це "брудним злом"?

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

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

Досить просто, щоб бути реалізованим.

Саме те, що потрібно, якщо я правильно зрозумів питання.

Я фактично створюю додаток, який займається цим.

Я почав зі створення сервісу RESTful за допомогою Django, Guradian та Tastypie. Він автентифікується лише за допомогою APIKEY, авторизація об'єктів обробляється Guardian.

Додаток django має лише один перегляд шаблону urlconf, що завантажує base.html, який є ...

На стороні клієнта я створив додаток за допомогою Angular.

Що стосується автентифікації, існує http-auth-перехоплювач, який слухає 401 відповідь.

Коли номер 401 отриманий, він буферизує вихідний запит і запускає подію, "потрібна для входу". Це може статися кілька разів.

У мене є модальне спливаюче вікно, що містить форму входу, яка подається, коли лунає подія "необхідний вхід", і вона виконує логін, який повертає ресурс користувача (пакет JSON), який також містив би APIKEY.

Усі запити на буфер, які раніше привели до відповіді 401, відтворюються разом із APIKEY, що тепер включений у заголовк http Авторизація.

Я використовую інший кутовий сервіс / завод для управління даними json localstorage, і саме там я зберігаю ім'я користувача та apikey.

Єдиний фрагмент головоломки, який залишився вирішити, - як захистити цю інформацію та як застосувати тайм-аут на цю інформацію.

Можливо, використовуйте перевірку часової позначки з останнього дійсного запиту http.

У моєму випадку я використовую щось подібне до 4.1. Після того, як користувач увійде в дуже легкий кутовий AJAX, запит json надходить до API REST через встановлені інтервали проти сервера. Через вимоги безпеки власний інтерфейс передбачає, що сервер буде підтримувати сеанс для користувача, який зберігає деяку захищену інформацію, шаблони, дані тощо на стороні сервера. Це все ще мій кращий метод з точки зору безпеки. У роботі з конфіденційними даними (а не просто хешованими паролями та подібними), IMO, що зберігає його на стороні клієнта в локальному сховищі тощо, становить більший ризик, ніж на сервері (я впевнений, що хтось погодиться зі мною). Треті сторони використовують один і той же API під час спілкування з системою, але повинні надсилати дані автентифікації на кожен запит.

Сеанс на сервері має до нього застосований максимальний час простою, і двигун зберігання сеансу зберігається (що також застосовується максимальний термін служби, в який момент сеанс пам’яті буде позначено закінченим). Термін експлуатації повинен бути лише більшим, ніж будь-який час сеансу, який ви абстрагуєте у своїй заявці (і це не повинно бути моїм значно). EG Сеанс може не закінчитися, поки він не буде працювати в режимі очікування протягом 48 годин, якщо це стосується сервера, але ваш код контролює фактичний термін служби. Це може призвести до проблем з ресурсами, якщо цей термін служби занадто великий, а ви керуєте сесіями поганою роботою.

У моєму випадку різні користувачі можуть мати різні час очікування сеансу в залежності від їх ролі в організації. Сервер встановлює максимальні обмеження на час роботи сеансу, але поки обмеження, визначені користувачем, менші, ніж обмеження, це працює чудово. Як тільки сервер закінчує сеанс, це суперечка, оскільки процес закінчення сеансу програма вже оброблятиметься програмою. Це вимога того типу ділового додатку, який я створив.

Після того, як сеанс роботи в режимі очікування і знаходиться в межах визначеного додатком порогу, API доручить користувальницькому інтерфейсу відобразити діалогове вікно зворотного відліку (як це роблять банки), і коли воно буде в межах певної відстані в часі від закінчення терміну дії, воно витончено вилучає користувача. Ця функціональність зберігається у вікнах браузера (оскільки сервер перебуває під керуванням), і неактивна подія в будь-якому вікні розпочне витончений таймер та автоматизований процес виходу (і триматиме їх у синхронізації).

Якщо випадково сеанс закінчується непристойним чином (сеанси завантажуються на запам’ятовується), наступний запит, який впливає на сервер, сповістить про це користувача і перемістить їх назад у квадратний (рідко трапляється, але може).