Session Timeout

Создание сообщества Данные и отчетность
41

Я понимаю вашу логику, Стивен, но это не паникерство.

Сотрудники IT ежедневно имеют дело с неосведомленными и так называемыми «глупыми» пользователями. Мы стараемся внедрять системы, способные справиться с любыми непредвиденными ситуациями, и это нелегко. В наши дни идентификация играет огромную роль, и лишь тестирование выявило эту проблему. Было бы приятно получить предупреждение, особенно учитывая, что этот вопрос обсуждался (и после исправления) еще с 2016 года.

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

42

А что, если пользователь забудет закрыть браузер? Как это тогда работает?

Мне, правда, интересно, @falco, почему патч 2016 года был отменён? Это небезопасное изменение?

43

Некоторые справедливые замечания.

Однако меня несколько шокировали несколько ваших примеров:

Больницы: Те, в которых я бывал за последние несколько лет, определённо имеют уникальные блокировки сессий, причём до такой степени, что медсестра, проводящая анализы крови, вынуждена снова входить в систему после того, как отойдёт всего на пару секунд.

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

Библиотеки:
Во всех моих местных публичных библиотеках (включая некоторые очень маленькие города и не слишком технически подкованный персонал) используется общий ID для входа. (Одинаковый для всех посетителей, размещён прямо на мониторе) Также у них действует политика перезапуска при уходе, и от всех, включая детей, ожидается её соблюдение. Последовательность перезапуска включает автоматическую очистку истории браузера, кэша и файлов cookie.

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

44

Хронология событий:

  • 2012 – май 2016: куки сессии Discourse всегда устанавливалась как «навсегда».

  • Май 2016 – июль 2016: куки сессии Discourse по умолчанию устанавливалась как «навсегда», но настройка сайта позволяла отключать её при закрытии браузера.

  • Июль 2016 – настоящее время: куки сессии Discourse устанавливается на 1440 часов и обновляется при использовании. Настройка сайта позволяет контролировать максимальный срок жизни. Настройка куки сессии браузера удалена.

Это было в основном удалено, потому что:

Я понимаю, что в некоторых частях мира идея совместного использования компьютеров с незнакомцами кажется совершенно чуждой, ещё больше это касается личных мобильных устройств, а теперь и в условиях COVID-19. Однако для таких мест, как школьные библиотеки, рабочие места и т. д., это вполне распространённая практика.

В большинстве случаев после использования они просто выключают компьютер. Выключение компьютера закрывает браузер, поэтому выключение компьютера косвенно завершает сеанс входа в веб-приложения.

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

45

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

максимальный возраст сессии [по умолчанию 1440 часов]

Пользователь останется в системе в течение n часов с момента последнего посещения. При значении 0 пользователь будет разлогинен при закрытии браузера.

46

Больницы: Я делюсь только тем, что знаю из собственного опыта. Согласен, что экраны быстро блокируются, но это не выход из браузера и уж тем более не выход пользователя из операционной системы. Можете ли вы представить, что бы сделали люди, если бы компьютер должен был выполнить вход, применить политики, настроить сетевые подключения — и только после этого загрузить какое-либо приложение, необходимое врачам и медсёстрам для выполнения своих задач, пока кто-то умирает? По схожей причине вход в систему обычно осуществляется не по логину и паролю, а с помощью бейджа и короткого PIN-кода по той же причине. В отделениях неотложной помощи, операционных и большинстве других помещений всё ещё необходимо документировать информацию о пациентах, поэтому в тех местах, где я работал, подход был последовательным повсеместно.

Библиотеки: Существуют политики перезагрузки при выходе из системы, и они эффективны, пока администраторы вручную очищают кэши всего на компьютере, но я видел множество мест, где поступают иначе (одна из многих причин, по которым я никогда не использовал общие рабочие станции с моими учётными данными). Я регулярно сталкивался с аналогичной неудачной конфигурацией в отелях и интернет-кафе (или кофейнях), на всякий случай.

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

Требовать от пользователей понимания того, что они должны вручную очищать куки-файлы сайта для выхода из системы, когда многие сайты как истекают по времени сессии, так и завершают её при закрытии браузера, кажется чрезмерным требованием. Полное отсутствие альтернативы, вынуждающей пользователя помнить о необходимости использовать конкретную ссылку выхода из Discourse, становится проблемой, если пользователь по какой-либо причине пропускает эту ссылку; на ум приходят следующие случаи:

Пользователь уходит с Discourse, перейдя по ссылке.
Пользователь уходит с Discourse, потому что использует вкладку для перехода в другое место.
Пользователь быстро закрывает вкладку, чтобы пойти на урок/встречу и т. д.
Браузер падает по любой причине.
Разработчик SSO использует SAML для входа, но не знает, что приложение требует явного выхода для завершения сессии приложения.

Кроме того, два (2) месяца кажутся ОЧЕНЬ долгим сроком для сохранения входа. Я знаю, что некоторые другие сайты сегодня могут делать так или даже дольше, но пользователи обычно могут контролировать это с помощью флажков «Общественный компьютер», что не применимо к SSO или, возможно, вообще не работает (я не гуру Discourse).

Просто ещё несколько мыслей для размышления.

47

У меня тоже эта проблема, и я не знаю, как её решить.

48

Спасибо за это, @codinghorror. Каков процесс и сроки для оценки и внедрения этого?

49

Не знаю, это зависит от технической сложности изменения. @sam, что ты думаешь о сложности того, что предлагается в моём сообщении выше?

50

Я тоже думаю, что это была бы крутая фича, так как это позволит людям понимать, кто действительно онлайн, а кто просто AFK.

51

Нам действительно нужно добавить новую настройку сайта, так как это концептуально независимая задача, и без неё код станет сложным для понимания.

В частности, нам нужно будет добавить минимальные значения здесь:

и ещё в нескольких местах, чтобы обеспечить корректную работу кода.

Нам нужна отдельная настройка типа «автоматически разлогинивать пользователей при закрытии браузера».

Продолжительность сессии всё равно применяется, даже если используются cookie-файлы сессии (то есть параметр expires не указывается).

Например, можно сказать:

  1. Если пользователь закрывает ноутбук и открывает его через 3 часа, он должен быть разлогинен.
  2. Если пользователь закрывает Chrome, он тоже должен быть разлогинен.

Это разные аспекты.

Может быть, добавим настройку persistent_sessions со значением по умолчанию true? «При значении true сессия сохраняется после закрытия браузера». Это изменение займёт около 20 минут.

52

Ладно, если отдельная настройка сайта лучше и это займёт всего 20 минут, то я за то, чтобы сделать это.

53

Может быть, в будущем эту хорошую идею можно будет расширить для настройки «на пользователя» вместо настройки только «на сайт»?

54

Теперь это настраивается для каждого сайта отдельно.

https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171

Мне кажется, это действительно выбор администратора. Это функция безопасности. В долгосрочной перспективе мы можем рассмотреть возможность создания списка разрешённых IP-адресов, которые будут обходить это ограничение (например, компьютеры в корпоративной сети останутся в системе, а компьютеры за её пределами будут автоматически выходить из системы).

55

По своей сути эта функция является индивидуальной для каждого пользователя.

Некоторые пользователи работают со своих домашних или офисных компьютеров, и им не требуется, чтобы куки (cookie) истекали; поэтому это должно оставаться на их усмотрение.

Другие пользователи — это «номады», работающие в кафе на общих компьютерах, и им важно, чтобы их сеансы истекали.

Поскольку данная функция касается безопасности учетной записи пользователя, такая настройка традиционно реализуется как опция или чекбокс, который пользователь выбирает при входе в систему.

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

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

Обновление: Если у пользователя привилегированная учетная запись (администратор, модератор, лидер и т. д.), то возникает также более масштабный вопрос общей безопасности сайта.

56

Я видел это, реализованное на многих-многих сайтах, типичная реализация:

Оставаться в системе в течение 30 дней

[ ВХОД ]

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

57

Спасибо всем! Ваша помощь и понимание очень ценны.

58

Спасибо.

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

Спасибо за отличную работу вашей команды. Молодцы.

59

Прежде всего: большое спасибо за быстрое исправление. Однако у меня есть один вопрос: можно ли сделать это настройкой на уровне пользователя с определённым значением по умолчанию, чтобы пользователи могли отключить её в своих настройках?

60

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

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