49581 2024-03-01 11:34:48 +0300 Диалог смены пароля 2024-03-05 01:18:30 +0300 1 1 4 Development Sisyphus lightdm-gtk-greeter unstable x86_64 Linux NEW P5 normal --- 1 cas manowar manowar max.gordeef rider shevchenkodyu qa-sisyphus oldest_to_newest 242422 0 cas 2024-03-01 11:34:48 +0300 Необходим более удобный интерфейс для замены пароля в случае его устаревания. 1. Свести все диалоги ввода на одно пространство. 2. Сразу выполнять (или настроить) индикацию политики сложности пароля (информацию брать из домена или локально из файла конфигурации). При сбое не повторять все шаги заново. 3. Добавить полноценную локализацию сообщений. 242436 1 manowar 2024-03-01 15:39:59 +0300 Андрей, что означают загадочные слова про "одно пространство"? 242453 2 cas 2024-03-02 08:04:13 +0300 (Ответ для manowar@altlinux.org на комментарий #1) > Андрей, что означают загадочные слова про "одно пространство"? В одном окне одновременно. 242527 3 manowar 2024-03-04 15:05:40 +0300 Теперь понял. А есть хотя бы примерное представление о том, как можно это реализовать? Для этого нужно как-то предсказывать, какие запросы будут поступать от ОС в процессе аутентификации. 242530 4 cas 2024-03-04 15:31:53 +0300 (Ответ для manowar@altlinux.org на комментарий #3) > Теперь понял. > > А есть хотя бы примерное представление о том, как можно это реализовать? Для > этого нужно как-то предсказывать, какие запросы будут поступать от ОС в > процессе аутентификации. Верно. Может, вообще сделать глубоко переработанный greeter? 242535 5 manowar 2024-03-04 18:33:00 +0300 Мне кажется не обоснованно сложным перерабатывать гритер, в то время как вся остальная часть операционной системы, которая работает до гритера, построена по совершенно другой логике. Это будет борьба со следствием, а не с причиной. Вот тебе пример. Допустим, у пользователя A криво отображается сайт S. Мы выясняем, что сайт S действительно содержит ошибку, но исправить сайт мы, понятное дело, не можем. Однако, мы можем добавить в браузер нашлёпку, которая исправит отображение. Сделать это возможно, но мудрым и технологичным такое "решение" не назовёшь: оно получится одновременно и сложным и очень хрупким. Я согласен добавить в гритер поддержку num_msg > 1. Но только после того, как у нас появится модуль, который будет отправлять в pam_conv() такие сгруппированные запросы. Тогда пишем в pam.d/lightdm нужную опцию или как-то ещё сообщаем модулю, что мы умеем num_msg > 1 и будет всё целыми диалогами, как ты хочешь. 242539 6 rider 2024-03-04 19:30:28 +0300 Глубоко переработанный sddm уже есть и именно поэтому мы от него отказались. Надо идти с архитектуры и смотреть что передаёт PAM, а если этих данных недостаточно - думать как их добавить. 242542 7 manowar 2024-03-05 01:18:30 +0300 Не достаточно. PAM передаёт по 1 сообщению за раз, хотя гипотетически, мог бы весь очередной диалог стазу передавать. Тогда num_msg обрело бы какой-то смысл. Антон прав, без изменения самой логики аутентификации эту проблему не решить. То есть, нужна не глубокая переработка гритера, как сказал Андрей, но переработка _в глубине_ системы. Возможно, не слишком большая.