datagridView u.a. mit Passwort-Spalten

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von BigBen2003.

    datagridView u.a. mit Passwort-Spalten

    Hallo,

    in einem DataGridView werden u.a. auch Passworte im Klartext angezeigt.

    Diese sollen mit einem Zeichen maskiert werden.

    Dazu habe ich folgenden Code

    VB.NET-Quellcode

    1. Private Sub DataGridView_EditingControlShowing(sender As Object, e As DataGridViewEditingControlShowingEventArgs) Handles DataGridView.EditingControlShowing
    2. Dim t As TextBox = e.Control
    3. If t IsNot Nothing Then
    4. t.UseSystemPasswordChar = True
    5. End If
    6. End Sub


    Dieser Code bewirkt allerdings, dass bei sämtlichen Textboxen innerhalb der Tabelle der Inhalt durch ein Zeichen maskiert wird, sobald dieser bearbeitet wird.

    Die Eigenschaft e.Control.Name enthält entgegen meinen ersten Vermutungen nicht den Name der Spalte, in der ein Eintrag zum Bearbeiten angeklickt wurde.

    Der obige Code wirkt sich in keinster Weise auf die Anzeige der Inhalte aus. Passworte werden innerhalb der Tabelle weiterhin im Klartext angezeigt.

    Im Internet habe ich folgende Webseite gefunden: social.msdn.microsoft.com/Foru…-passwords?forum=winforms

    Da die bei der Umwandlung des C#-Codes zu einem VB.net-Codes diverse Fehler angezeigt werden, wurde kurzerhand dem vorhandenem VB.net-Projekt ein weiteres C#-Projekt mit der Klasse PasswordBox.PasswordBox hinzugefügt.

    Aus der Webseite werden Lösungsansätze diskuiert, um Passworte inerhalb einer DataGridView zu maskieren.

    Bis dato habe ich nicht herausbekommen, wie die Lösung angewandt werden soll.

    Kann mir jemand weiter helfen?

    Verschoben. ~Thunderbolt

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Thunderbolt“ ()

    (Link zu einem anderen Thread nachträglich entfernt)

    Bevor jetzt Lösungen angeboten werden, stellt sich die Frage, ob es sinnvoll ist, Passwörter als Klartext zu speichern. Maskierung hin oder her.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „VaporiZed“ ()

    Hallo,

    klar, das hätte ich noch dazu setzen sollen:

    Das Passwort wird anschließend mit der TrippleDES-Methode ( msdn.microsoft.com/de-de/library/bb978948.aspx ) verschlüsselt, bevor es gespeichert wird. Aber das ist eine andere Baustelle, die noch die bis dato nur geplant wurde. Ich mach ungern mehrere Baustellen auf. :)

    Vollzitat entfernt. ~Thunderbolt

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Thunderbolt“ ()

    BigBen2003 schrieb:

    Die Eigenschaft e.Control.Name enthält entgegen meinen ersten Vermutungen nicht den Name der Spalte, in der ein Eintrag zum Bearbeiten angeklickt wurde.
    na, dann guck die anderen Member von e an - etwa e.ColumnIndex hat ja was mit Spalten zu tun.

    (Übrigens hasse ich das, in eine PasswortChar-Textbox tippen zu müssen. Dankenswerterweise hat so gut wie jede Anmeldung heutzutage in ieiner Form ein Feature, dass man auch mal sehen kann, was eingetippt ist.
    (aber allein son Feature auch noch dranzumachen ist auch eine Baustelle))
    Warum verwendest du keinen SecureString für Passwörter und konvertierst den, wenn es gespeichert wird in einen String?

    Muss das Passwort im DataGrid bearbeitet werden? Ansonsten würde ich den Eintrag "faken" und einen String mit "*******" anzeigen lassen. Also für jedes Passwort die gleiche länge an chars :)
    In etwa so: github.com/BornToBeRoot/NETwor…CredentialsView.xaml#L155

    Und die Konvertierung SecureString to String: github.com/BornToBeRoot/NETwor…ers/SecureStringHelper.cs
    NETworkManager - A powerful tool for managing networks and troubleshoot network problems!
    Hallo BornToBeRoot,

    das ist ein guter Einfall, dann kann ja geich der SecureString direkt ans DataSet übergeben werden.

    Statt den Fake "*****"-Eintrag würde ich lieber ein Button vorziehen. Nach dem Anklicken öffnet sich ein Simple MessageBox (oder Mini-Form mit zwei Maskierten Textboxen und einem Button?) mit der Eingabe des Passwortes in doppelter Ausfertigung. Einträge werden nur übernommen, wenn beide Einträge identisch sind.

    Hier wird erläutert, wie in einem Datagridview ein Button eingesetzt werden kann: vb.net-informations.com/datagr…t_datagridview_button.htm

    BigBen2003 schrieb:

    Hier wird erläutert, wie in einem Datagridview ein Button eingesetzt werden kann
    Das sollte man besser im Form-Designer machen.
    also der Artikel ist soweit richtig, dass Dgv "high-configurable" ist, aber wie high scheint dem Autor unbekannt zu sein.
    Ist ja aber auch bisserl mühsam zu verschriftlichen, wie man den Dgv-SmartTag benutzt - dann Edit Columns, und dann eine ButtonColumn einsetzen.
    Einfacher ists, Code zu zeigen, der im Control herumhühnert.

    Also auf vier Views-Videos wird in verschiedenen Filmen gezeigt, wie man eine ComboboxColunmn einbastelt - ButtonColumn ist prinzipiell dasselbe, sogar deutlich einfacher.
    Hallo,

    vielen Dank für die Informationen. Die vier Videos sind wirklich Gold wert. Man sollte Dir dafür sogar einen Orden verleihen, da hier der Inhalt für Anfänger sehr anschaulich rübergebracht wird.

    Zitat von ErfinderDesRades:
    (Übrigens hasse ich das, in eine PasswortChar-Textbox tippen zu müssen. Dankenswerterweise hat so gut wie jede Anmeldung heutzutage in ieiner Form ein Feature, dass man auch mal sehen kann, was eingetippt ist.
    (aber allein son Feature auch noch dranzumachen ist auch eine Baustelle))


    Genau deshalb werde ich ein Button mit einem "Auge" neben der Textbox platzieren. Nach dem Anklicken kann der Anwender das Passwort in Klartext sehen.

    Habe inzwischen hinbekommen, im DataGridView in einer Spalte Buttons zu nehmen. Beim Anklicken wird ein Panel eingeblendet, in dem weitere Textboxen enthalten sind.

    Bisher hatte ich immer die Situation gehabt, dass für jedes Textfeld ein Datenfeld zur Verfügung stand. Somit war die Aufgabe relativ leicht zu bewältigen, indem die Verbindung eines Textfeldes mit einem Datenfeld hergestellt wurde.

    Nun soll das Passwort allerdings zweimal identisch eingegeben werden. Im Dataset gibt es allerdings nur ein Passwort-Feld.

    Daneben gibt es noch zwei Options-Radio-Buttons, in dem festgelegt werden soll welche Angabe überhaupt verwendet werdn soll, SSH-Key oder Passwort. Das bedeutet, dass die Optionsfelder beim Anzeigen ebenfalls gesetzt werden müssen, obwohl es hier kein Feld gibt. Programmatisch wird das nur ermittelt, indem eines der Eingaben auf Nothing steht.

    mein erster Gedanke ist, zwischen dem Dataset und dem Textfeld eine Klasse dazwischen zu schalten, mit der die zusätzlichen Controls gesetzt werden und auch auf Eingaben durch den Anwender reagiert werden kann. Zusätzlich kann in der Klasse die Eingaben validiert und die Angaben erst dann dem Dataset übergeben werden, sobald die Validierung erfolgreich abgeschlossen ist.

    Oder ist es üblich, das die Steuerung der Dataset-gebundenen-Controls direkt im Userform abgewickelt wird? In dem Falle ist es mir allerdings schleierhaft, wie man die zusätzlichen Control-Elemente mit Werten "füttern" soll.

    Achtung, jetzt kommt ein kurzer Rückblick auf VBA-Zeiten :) :
    Bislang hatte ich meistens als Frontend mit einer Office-Userform zu tun gehabt, die dann mit Microsoft Word, oder Excel geöffnet wurde. Hier gibt es keine dynamischen Databindings. Die Controls mussten alle mit entsprechendem VBA-Befehlen gefüllt und vor dem schließen wieder zurück geschrieben werden. Da konnte die ganze Programm-Logig innerhalb der Userform ablaufen.

    Nun, mit .net sind mit die Databinding-Controls ganz sympatisch geworden. Da können sogar aus dem aktuellem Datensatz einer DatagridView weitere Controls mit Angaben gefüllt werden. Und nicht nur das; die Angaben werden sogar wieder zurück geschrieben, nachdem diese durch den Anwender geändert worden sind. Das geschiet alles mit wenig Source-Code. Wenn das alles mit VBA-Befehlen umgesetzt werden sollte, muss dafür schon sehr viel Source-Code geschrieben werden. Das ist eine große Erleichterung.

    Vielleicht gibt es hierzu einige Webseiten, in denen die übliche Vorgehensweise erläutert wird?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „BigBen2003“ ()

    ErfinderDesRades schrieb:

    übliche Vorgehensweise für was?


    ich meinte die übliche Vorgehensweise beim Erstellen einer .net Anwendung mit einer DatagridView,Controls eingesetzt werden, die nicht direkt mit einem Dataset verbunden werden können.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „BigBen2003“ ()

    da habe ich doch in post#7 paar Filmle zu verlinkt.

    Ansonsten ist "üblich" ja ein dehnbarer Begriff. Nur vergleichsweise wenige wissen um die "DatagridView-Power", wie sie in den Filmen gezeigt ist, und wie sie ja wohl offensichtlich als Vorgehensweise vorgesehen ist, sonst hätte man das Dgv ja nicht damit ausgestattet.
    Wenns also nur wenige wissen, dann kann man es auch als "üblich" bezeichnen, wenn das Dgv mehr oder weniger weit unter seinen Möglichkeiten genutzt wird.

    ah - dassis gemein, deinen Post zu ändern, nachdem ich geantwortet habe.
    Der Satz ist jetzt kein wirklich verstehbares Deutsch mehr, also ich wiederhole ihn mal, wie mir zusammenreime, dasser gemeint sein könnte:
    ich meinte die übliche Vorgehensweise beim Erstellen einer .net Anwendung mit einer DatagridView, wenn auch Controls eingesetzt werden, die nicht direkt mit einem Dataset verbunden werden können.

    Da gibts natürlich keine übliche Vorgehensweise - darunter fällt ja einfach alles, was überhaupt irgend möglich ist.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Sorry für meine schlechte Erläuterungen, ich habe das Anliegen nicht nicht klare Worte verfassen können..

    In der Zwischenzeit ist mir diese Webseite aufgefallen: msdn.microsoft.com/de-de/libra…validating(v=vs.110).aspx

    In dieser wird u.a. erläutert, welche Events für die Datenüberprüfung herangezogen werden können.

    Mit dem Event "Validating" können beide Passwort-Eingaben geprüft werden, ob diese identisch sind. Falls diese nicht identisch sein sollten, wird eine Übernahme verweigert.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „BigBen2003“ ()