Сочетания клавиш для подтверждения, устойчивые к случайным срабатываниям

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

Такую ошибку легко выпустить в продакшен, потому что основной сценарий выглядит отлично. Разработчик запускает действие, появляется окно подтверждения, Return принимает его, и все называют взаимодействие быстрым. Затем тот же разработчик читает вывод терминала, удерживает модификатор при переключении окон или нажимает Return, чтобы закрыть посторонний запрос. Подтверждение приходит не вовремя, и действие получает согласие, которого никто осознанно не давал.

Сочетание клавиш подтверждения является границей безопасности

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

Есть три разных факта, которые команды регулярно сводят к одному:

• Процесс может запросить действие.
• Человек может находиться за компьютером.
• Этот человек может прямо сейчас подтвердить именно это действие.

Первый факт связан с идентичностью процесса. Второй говорит о присутствии человека рядом с компьютером. Третий означает авторизацию. Подписанный процесс хорошо подтверждает первый факт. Видимое окно может указывать на второй. Ни один из них не доказывает третий.

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

Распространённая ошибка в реализации, привязать сочетание к общему обработчику команд и проверять только существование окна подтверждения. В демонстрации это выглядит безобидно. В работе событие, доставленное с задержкой, может подтвердить другой запрос, старый запрос после замены или окно, которое только что вернулось из фона. Кнопке не обязательно было быть видимой в тот момент, когда человек нажал клавишу.

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

Это меняет подход к ревью кода. Спрашивайте «какое именно событие может пересечь эту границу?», а не «нажатие Return активирует кнопку?». Хороший ответ называет источник события, состояние окна, идентификатор запроса и случаи отказа. Фраза «диалог открыт» ответом не является.

Фокус нужно доказывать, а не предполагать

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

Рассмотрим распространённую последовательность. Агент выполняет команду в терминале. Пользователь вводит команду, переключается на документацию, а затем появляется модальное окно авторизации. Операционная система меняет активное окно, пока руки пользователя ещё движутся. В зависимости от порядка событий и фреймворка приложения нажатие Return может попасть в модальное окно уже после получения им фокуса, хотя намерение возникло до того, как пользователь его увидел.

Небезопасное правило выглядит просто: если кнопка авторизации является кнопкой по умолчанию и окно находится на переднем плане, принять Return. Это правило считает положение окна на переднем плане доказательством того, что человек увидел и оценил запрос. На деле оно доказывает лишь то, что в момент доставки события окно находилось впереди остальных.

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

Это намеренно консервативный подход. Пользователю, который переключился на другое окно и вернулся, придётся ещё раз нажать сочетание после возвращения. Это недорого. Случайно отправить HTTP-вызов с учётными данными или команду SSH гораздо опаснее.

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

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

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

Для удерживаемого ввода нужна отдельная машина состояний

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

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

Отслеживайте физический жизненный цикл каждого принимаемого сочетания. Диалог может принять сочетание только после того, как увидит новое событие нажатия без повтора, произошедшее после его собственной эпохи активации, пока он находится в фокусе, а затем получит завершение по правилам вашей платформы. Если при открытии диалога клавиша уже нажата, установите для неё блокировку и ждите события отпускания. Не считайте повтор новым нажатием.

К Space нужно относиться так же внимательно, как к Return. Многие элементы управления используют Space для активации с клавиатуры, а люди удерживают Space для предварительного просмотра, прокрутки или функций доступности. Escape тоже требует проверки. Она должна отменять только отображаемый текущий запрос и не отменять заменивший его запрос, появившийся после нажатия.

Для сочетаний с модификаторами нужна более строгая политика. Не считайте одно лишь состояние модификатора разрешением и избегайте сочетаний, совпадающих с терминальными привычками, например Control-C, Control-D или Control-R. Если вы выбираете комбинацию, требуйте, чтобы всё сочетание началось после активации диалога, и отклоняйте его, если фокус изменился, пока какая-либо клавиша была нажата. Комбинация, начавшаяся в другом окне, не является решением о вашем диалоге.

Достаточно небольшой внутренней записи:

\nrequestId: 84f2\nfocusGeneration: 17\narmedAfterEvent: 912\nreturnIsBlockedUntilUp: true\napprovalState: pending\n

Названия не важны. Важно правило: событие должно быть новее текущего поколения фокуса диалога и относиться к новому жизненному циклу ввода. Команды часто добавляют такое состояние после сообщения о случайном подтверждении. Добавьте его до реализации сочетания.

Время появления модального окна превращает обычный ввод в авторизацию

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

Стоит назвать несколько временных разрывов. Запрос может прийти между нажатием и отпусканием клавиши. Интерфейс может отрисоваться до того, как состояние приложения завершит привязку идентификатора запроса. Предыдущий запрос может закрыться, пока обратный вызов в очереди всё ещё хранит обработчик завершения. Новое диалоговое окно может повторно использовать тот же объект кнопки, и старое клавиатурное действие окажется направлено на новое содержимое.

Типичный сбой выглядит так:

1. Пользователь нажимает Return в терминале, чтобы отправить команду.
2. Процесс агента запрашивает разрешение, пока нажатие ещё обрабатывается.
3. Приложение показывает диалог подтверждения и активирует кнопку по умолчанию.
4. Отпускание клавиши или повторное событие попадает новому обработчику.
5. Приложение воспринимает событие как подтверждение и отправляет действие.

Пользователь может вообще не прочитать диалог. При этом приложение записывает в аудит, что пользователь подтвердил действие, и проблема становится ещё серьёзнее. Запись точно описывает путь в коде, но ложно описывает поступок человека.

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

Используйте поколения запросов наряду с поколениями ввода. Привязывайте действие каждой кнопки и обработчик клавиатуры к неизменяемому токену запроса. При закрытии диалога отзывайте этот токен. При замене запроса создавайте новый токен, а не изменяйте старый объект. Обратный вызов со старым токеном должен вернуть отказ, даже если в этот момент видно новое диалоговое окно.

Не пытайтесь решить проблему времени одной задержкой вроде «игнорировать Return в течение 300 миллисекунд». Задержки популярны, потому что их легко объяснить и реализовать. Они ломаются на медленных компьютерах, при быстрой смене фокуса, использовании специальных средств ввода и при более медленной реакции пользователя. Задержка измеряет время. Вам нужно измерять связь между событием ввода и текущим состоянием диалога.

Терминальные привычки опасны для ввода

Работа в терминале создаёт именно те нажатия, которым окно подтверждения должно не доверять. Разработчики нажимают Return для отправки команд, Control-C для остановки работы, Space для постраничного просмотра вывода и Escape для отмены редактирования. Агенты делают работу в терминале более частой, поэтому окно авторизации может появиться рядом с потоком привычного ввода.

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

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

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

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

Проверяйте настоящий сценарий работы в терминале, а не только синтетическое окно. Запустите команду, которая несколько раз запрашивает ввод, вызовите запрос во время нажатия Return и протестируйте поведение после Control-C и Space. Проверьте случаи, когда фокус находится в терминале, в окне документации и когда окно авторизации появляется во время переключения окон. Цель, воспроизвести намерение, начавшееся в другом месте.

Проверяйте историю событий, а не нарисованную кнопку

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

Представьте диалог явными событиями, например present, focusGained, focusLost, keyDown, keyRepeat, keyUp, requestRevoked и approveClick. Каждому событию назначьте токен запроса и монотонно возрастающую последовательность ввода. Редуктор должен выдавать один из трёх результатов: оставить запрос ожидающим, отменить его или выдать подтверждение для совпадающего токена.

Этот пример достаточно мал, чтобы хранить его рядом с кодом взаимодействия:

[\n  {\"seq\": 41, \"type\": \"keyDown\", \"key\": \"Return\"},\n  {\"seq\": 42, \"type\": \"present\", \"request\": \"r-19\"},\n  {\"seq\": 43, \"type\": \"focusGained\", \"request\": \"r-19\"},\n  {\"seq\": 44, \"type\": \"keyUp\", \"key\": \"Return\"},\n  {\"seq\": 45, \"type\": \"keyDown\", \"key\": \"Return\"},\n  {\"seq\": 46, \"type\": \"keyUp\", \"key\": \"Return\"}\n]\n```

Не менее важна форма ожидаемого результата:

```json
[\n  {\"seq\": 44, \"decision\": \"pending\", \"reason\": \"inherited-input\"},\n  {\"seq\": 46, \"decision\": \"approved\", \"request\": \"r-19\"}\n]\n```

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

Составьте компактную матрицу тестов вокруг изменений состояния, а не подписей. Как минимум проверьте такие случаи:

- Сочетание нажато до показа окна и отпущено после появления фокуса.
- После начала нового нажатия фокус уходит и возвращается до отпускания клавиши.
- Пока запрос остаётся ожидающим, приходит событие повтора.
- Запрос A закрывается, открывается запрос B, а затем срабатывает старый обработчик.
- После появления диалога хранилище или другая необходимая предпосылка меняет состояние.

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

Затем проверьте интеграцию с интерфейсом, где многие хорошие редукторы обходят сами. Убедитесь, что каждый путь активации проходит через одну и ту же проверку: щелчок указателем, Return, Space, действие специальных возможностей, программный вызов кнопки по умолчанию и команда меню. Отдельный путь сочетания, который напрямую вызывает действие, со временем начнёт отличаться от пути кнопки.

Используйте внедрение зависимостей для исполнителя действий в этих тестах. Тест должен получить объект вызова только после того, как редуктор выдал подтверждение для текущего токена. Считайте вызовы, сохраняйте токен запроса и завершайте тест с ошибкой, если до исполнителя дошёл старый токен. Не проверяйте это отправкой настоящего HTTP-запроса или команды SSH. Граница авторизации должна тестироваться без учётных данных и сети.

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

## Отклонённое событие должно оставаться отклонённым

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

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

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

Разделяйте результат для интерфейса и результат внешнего действия. Интерфейс может сообщить «подтверждено для отправки» только после закрытия состояния принятия решения. Затем исполнитель может независимо завершить действие успешно или с ошибкой. Если сетевой запрос завершился ошибкой, не активируйте старый токен подтверждения и не выполняйте скрытный повтор по следующему нажатию. Если пользователю нужно авторизовать новую попытку, запросите подтверждение снова, особенно если данные действия или адрес назначения могли измениться.

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

## На вопросы об идентичности, авторизации и области действия нужны разные ответы

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

Идентичность процесса полезна, потому что помогает человеку понять, ожидаем ли отправитель. В macOS полномочия подписи кода могут дать более понятный сигнал, чем изменяемое имя процесса. Но ожидаемый процесс всё равно может отправить неожиданный запрос, а человек может случайно подтвердить не тот запрос из-за лишнего нажатия.

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

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

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

## Выпускайте функцию только после того, как трассировка ошибки станет скучной

Выпускайте сочетание только тогда, когда враждебный ввод приводит к обычным и понятным отказам. Пользователь должен иметь возможность удерживать Return во время появления окна, переключать окна в середине комбинации, вызвать повтор Space или одновременно создать запрос на замену, не вызвав внешний вызов.

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

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

Хорошее сочетание клавиш подтверждения после просмотра запроса кажется обычным и незаметным. Только такую скорость стоит оптимизировать. Любой другой быстрый путь лишь превращает терминальную привычку в авторизацию.