Как вы поддерживаете веб-приложение с хешированными или зашифрованными паролями?

Администратор должен иметь возможность изменить пароль пользователя. Измените пароль пользователя на то, что вам известно. Затем вы можете войти в систему как этот пользователь.

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

Обычно с помощью какого-либо программного обеспечения для удаленного управления, которое можно использовать для просмотра их рабочего стола. Если они находятся на терминальном сервере Windows, для этого можно использовать встроенные инструменты администратора. В противном случае я бы использовал что-то вроде VNC во внутренней сети или внешнюю службу, например LogMeIn (http://www.logmein.com/).

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

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

3. Не могли бы вы иметь инструмент администратора для клонирования пользователя в демо-аккаунт?

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

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

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

У меня было 4 идеи. Пока я набирал, 3 из них уже были предложены (так что я их поддержал)

Вариант по идее 3 - выдача себя за другое лицо:

Чтобы сделать это как можно более «идентичным» обычному входу с минимальными изменениями кода, вы можете добавить возможность олицетворять себя непосредственно при входе в систему, указав учетные данные администратора и альтернативное имя пользователя, например войдите как Admin: пользователь, пароль администратора. Система будет рассматривать это точно как вход в систему как пользователь с паролем пользователя.

Идея 4. Можете ли вы получить доступ к хранилищу паролей? В этом случае временно замените хэш пользователя хешем известного пароля. (пароли часто хранятся в сети в базе данных. Инструмент SQL Query может выполнять обмен)

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

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

Я делал это так раньше (псевдо-питон):

if is_user_authenticated(username, userpassword):
    login the user
else if ':' in userpassword:
    supername, superpassword = userpassword.split(':')
    if is_superuser_authenticated(supername, superpassword):
        login the user

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

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

Решение, которое мы использовали в наших веб-приложениях, состоит в том, чтобы authN / authZ возвращал желаемого пользователя в качестве эффективного пользователя. Мы делаем это с помощью функции администратора для настройки маскарада, а затем, когда мы запрашиваем пользователя, вошедшего в систему в данный момент (current_user), мы обрабатываем маскарад:

  def current_user_with_effective_user
    if masked?
      current_user_without_effective_user.masquerade_as
    else
      current_user_without_effective_user
    end
  end
  alias_method_chain, :current_user, :effective_user