Verwenden von PasswordBox mit WPF - MVVM

8

Ich habe mehrere Artikel darüber gelesen, wie Attached Properties verwendet werden, um an den Wert einer PasswordBox in WPF zu binden. In jedem Artikel wird jedoch auf die .NET-Dokumentation verwiesen, die erklärt, warum die PasswordBox überhaupt nicht bindbar gemacht wurde.

Ich betrachte mich selbst nicht als Sicherheitsexperten, aber ich denke, dass jemand bei Microsoft wusste, was sie taten, und ich sollte nicht versuchen, den Fehler rückgängig zu machen.

Also, stattdessen habe ich meine eigene Lösung gefunden.

%Vor%

Dann rendere ich in meinem XAML nur die PasswordBox, indem ich das Passwort-Feld an ein ContentPresenter anbinde.

Meine Frage ist also ... gibt es ein Problem damit? Ich stelle fest, dass ich den MVVM auf eine Art und Weise durchbreche, indem ich tatsächliche Steuerelemente in meinem ViewModel erscheinen lasse, aber das scheint zumindest richtiger zu sein, als nur das Passwortfeld zu entsichern.

Wenn dies tatsächlich ein Problem ist, hat jemand eine Lösung gefunden, die nicht die Verwendung von angehängten Eigenschaften und das Speichern des Passworts im ViewModel beinhaltet?

Danke! -J

    
jeremyalan 09.08.2010, 21:57
quelle

4 Antworten

6

Was ist falsch daran, das Passwort mindestens solange in der VM zu speichern, wie es während der Anmeldung benötigt wird? Sie sind richtig, dass laut MVVM-Muster die VM keinen Verweis auf ein Steuerelement wie eine PasswordBox haben sollte.

Fügen Sie in der Ansicht einen Handler zum PasswordChanged-Ereignis hinzu. Aktualisieren Sie im Handler eine SecureString-Eigenschaft in der VM mit dem SecurePassword der Kennwortbox.

    
Wallstreet Programmer 09.08.2010, 22:19
quelle
2

es ist nur eine meinung hoffe es kann dir helfen.

  1. Ich denke, die Idee, Password nicht als DP zu verwenden, wird durch externe Software wie SNOOP leicht verfolgt.
  2. Die geringste Abhängigkeit von View Model, das Sie haben, desto besser ist Ihr Code. Es hilft Ihnen beim Komponententesten und beim Upgrade oder bei Änderungen (was würden Sie tun, wenn Sie in Zukunft ein Passwortfeld eines Drittanbieters verwenden möchten?)
  3. Wegwerfen Sie den Zustand "Code Behind is Useless" verwenden Sie es mit Bedacht.

Betrachten Sie dies in Ihrem Code hinter:

%Vor%     
ktutnik 10.08.2010 04:58
quelle
0

Ich mag Ihre Idee.

Ja, Sie verstoßen hier gegen Best Practices von ViewModel, aber

  • Best Practices sind "Empfehlungen, die in den meisten Fällen gut funktionieren" statt strikter Regeln und
  • das Schreiben von einfachem, leicht lesbarem, wartbarem Code und das Vermeiden unnötiger Komplexität ist ebenfalls eine dieser "Best-Practice" -Regeln (die durch die Problemumgehung "Attached-Eigenschaft" leicht verletzt werden können).

Ob das Brechen der View / ViewModel-Barriere hier ein Problem für Sie darstellt oder nicht, hängt davon ab, warum Sie ViewModels überhaupt verwenden (z. B. Trennung von Problemen, Komponententests, Wiederverwendbarkeit), also kann ich das nicht beantworten.

    
Heinzi 09.08.2010 22:30
quelle
0

meine 2 Cent:

Verschlüsseln Sie das Kennwort im Ansichtsmodell, verwenden Sie die angehängten Eigenschaften und verwenden Sie einen ValueConverter zum Verschlüsseln / Entschlüsseln des Kennworts. Selbst wenn jemand Snoop benutzt, sehen sie nur die verschlüsselten Daten.

Lassen Sie uns wissen, was am besten zu Ihrer Situation passt

    
nathan_hc 02.09.2010 03:31
quelle

Tags und Links