Использование PasswordBox с WPF - MVVM

Question

Я прочитал несколько статей о том, как использовать Attached Properties для привязки к значению PasswordBox в WPF.Тем не менее, каждая статья также ссылается на документацию .NET, которая объясняет, почему PasswordBox не был привязан в первую очередь.

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

Итак, вместо этого я придумал свое собственное решение.

public class LoginViewModel
{
   // other properties here

   public PasswordBox Password
   {
      get { return m_passwordBox; }
   }

   // Executed when the Login button is clicked.
   private void LoginExecute()
   {
      var password = Password.SecurePassword;

      // do more stuff...
   }
}

Затем, вмой XAML, я просто визуализирую PasswordBox, связывая поле Password с ContentPresenter.

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

Если это так, вФакт, проблема, кто-нибудь придумал решение, которое не включает использование Attached Properties и сохранение пароля во ViewModel?

Спасибо!-J

Answer 1

Что плохого в том, чтобы хранить пароль в виртуальной машине хотя бы тогда, когда он необходим во время входа в систему?Вы правы, что в соответствии с шаблоном MVVM виртуальная машина не должна иметь ссылку на элемент управления, такой как PasswordBox.

В представлении добавьте обработчик к событию PasswordChanged.В обработчике обновите свойство SecureString в ВМ с помощью пароля SecurePass для поля пароля.

Answer 2

это всего лишь надежда, что это поможет вам.

1. Я думаю, что идея не создавать пароль, поскольку DP легко отслеживается внешним программным обеспечением, таким как SNOOP.
2. Чем меньше у вас зависимости от View Model, тем лучше ваш код. это поможет вам в модульном тестировании и обновлении или изменениях (что бы вы сделали, если в будущем вы захотите использовать сторонний ящик с паролем?)
3. Выбросьте состояние «Код позади бесполезен», используйте его с умом.

Учтите это в своем коде:

void loginButton_Clicked(object s, EventArgs e)
{
    myViewModel.Password = txPwdBox.Password;
    myViewModel.Login();
}

Answer 3

мои 2 цента:

Зашифруйте пароль в модели представления, используйте вложенные свойства и используйте ValueConverter для шифрования / дешифрования пароля. при этом, даже если кто-то использует snoop, все, что он видит, - это зашифрованные данные.

дайте нам знать, что лучше всего подходит для вашей ситуации

Answer 4

Мне нравится твоя идея.

Да, вы нарушаете лучшие практики ViewModel, но

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

Будет ли проблема для вас преодолением барьера View / ViewModel здесь или нет, зависит от , почему вы используете ViewModels, в первую очередь (например, разделение задач, модульное тестирование, повторное использование) Я не могу ответить на это.