Whitespaces bei Validierung entfernen?

Hi,

sagen wir mal, wir haben eine Klasse "User". Diese Klasse hat die Attribute "Login" und "Passwort". Diese werden durch Getter und Setter definiert (getLogin/setLogin, getPasswort, setPasswort). Außerdem gibt es eine Methode "validate", die das Objekt validiert (z. B. prüft sie vielleicht, ob das Passwort sicher genug ist und sowas). Nun stellen sich mir zwei Fragen bzgl. der "best practice":

1. ich möchte, dass der Loginname vorne und hinten keine Whitespaces enthält. Diese Logik würde man dann in der setLogin implementieren, oder? Oder packt man das in die validate?

2. sollte man das Passwort auch trimmen oder lieber dem Benutzer eine Meldung ausgeben, dass ungültige Zeichen enthalten sind? Ich denke ja eher Letzteres.

Sqwan

zu 1) Ich würde es direkt im setter prüfen. Dann weißt du das im weiteren Verlauf immer ein vernünftiges password gesetzt ist. Auch wenn du deinen Code mal in einem anderen Projekt wieder verwendest.

zu 2) Bei der Passwort-Eingabe würde ich einfach trimmen. Bei der Registrierung allerdings warenen. Denn bei der Registrierung möchte der User vllt das Leerzeichen als Bestandteil des Namens nutzen.

zwutz

Sqwan schrieb:

Denn bei der Registrierung möchte der User vllt das Leerzeichen als Bestandteil des Namens nutzen.

Das will niemand der nicht absichtlich Verwirrung stiften will

Sqwan

zwutz schrieb:

Sqwan schrieb:

Denn bei der Registrierung möchte der User vllt das Leerzeichen als Bestandteil des Namens nutzen.

Das will niemand der nicht absichtlich Verwirrung stiften will

Das denke ich auch. Aber solche Leute gibt es halt. Und deshalb würde ich da, wie bereits beschrieben, warnen. Also es nicht erlauben. Die Warnung macht allerdings auch für user die ausversehen ein Leerzeichen vorweg haben Sinn. Allerdings könnte man um es Userfreundlich zu halten schreiben: "Ihr Account wurde erfolgreich erstellt. Alle führenden Leerzeigen wurden entfernt".

zwutz schrieb:

Sqwan schrieb:

Denn bei der Registrierung möchte der User vllt das Leerzeichen als Bestandteil des Namens nutzen.

Das will niemand der nicht absichtlich Verwirrung stiften will

PW = "Vorname Nachmane"

Und schon ist ein Leerzeichen drin.

Sqwan schrieb:

Allerdings könnte man um es Userfreundlich zu halten schreiben: "Ihr Account wurde erfolgreich erstellt. Alle führenden Leerzeigen wurden entfernt".

Das ist dann schnell weggeklickt und der User wundert sich beim nächsten Login, warum das Passwort nicht funktioniert.

Macht man es transparent, also entfernt man einfach das Leerzeichen sowohl beim Setzen als auch beim Login, dann läuft man Gefahr, dass der User ein zu kurzes Passwort produziert oder sich wundert, warum das Programm immer meldet, dass es zu kurz sei, obwohl es seiner Meinung nach lang genug ist.
Beispiel:

PW = " hh ";

Das ist ein Passwort dass aus 12 Zeichen besteht.
Wenn der Settercode nun die Leerzeichen wegoptimiert, dann sind es nur noch 2 und damit zu kurz.
Sollte es eine Warnung geben, dass das PW zu kurz ist, dann wird sich der User wunern, warum die 12 Zeichen nicht reichen.

Nochmal, habe leide die Code Tags vergessen:

zwutz schrieb:

Sqwan schrieb:

Denn bei der Registrierung möchte der User vllt das Leerzeichen als Bestandteil des Namens nutzen.

Das will niemand der nicht absichtlich Verwirrung stiften will

PW = "Vorname Nachmane"

Und schon ist ein Leerzeichen drin.

Sqwan schrieb:

Allerdings könnte man um es Userfreundlich zu halten schreiben: "Ihr Account wurde erfolgreich erstellt. Alle führenden Leerzeigen wurden entfernt".

Das ist dann schnell weggeklickt und der User wundert sich beim nächsten Login, warum das Passwort nicht funktioniert.

Macht man es transparent, also entfernt man einfach das Leerzeichen sowohl beim Setzen als auch beim Login, dann läuft man Gefahr, dass der User ein zu kurzes Passwort produziert oder sich wundert, warum das Programm immer meldet, dass es zu kurz sei, obwohl es seiner Meinung nach lang genug ist.
Beispiel:

PW = "    hh      ";

Das ist ein Passwort dass aus 12 Zeichen besteht.
Wenn der Settercode nun die Leerzeichen wegoptimiert, dann sind es nur noch 2 und damit zu kurz.
Sollte es eine Warnung geben, dass das PW zu kurz ist, dann wird sich der User wunern, warum die 12 Zeichen nicht reichen.

Sqwan

@Auskenner
Übliche trim funktionen wie es sie z.B. in PHP giebt entfernen nur Leerzeichen am Anfang und am Ende.
Und die Warnung muss man halt groß und rot machen.
Und am besten noch mal in die Confirmation.
Bei einem gefailten Login kann man auch drauf hinweisen das Leerzeichen entfernt werden

SeppJ

Sqwan schrieb:

Und die Warnung muss man halt groß und rot machen.
Und am besten noch mal in die Confirmation.

Genau. Damit der Nutzer auch ganz sicher diese Warnung uebersieht, da er nach vielen Jahren Internet- und Windowsnutzung dazu erzogen wurde, dass grosse rote Informationen und Bestaetigungen stets nur eines der Folgenden enthalten:
a) Werbung zum Uebersehen
b) AGBs zum Wegklicken
c) triviale Meldungen zum Wegklicken

Ich denke den zugang sollte man deshlab nicht verweigern.

12 buchstaben PWs mit vorangehenden 10 Leerzeichen würden ja eh nicht gehen weil sie eben nur 2 lang sind.

TyRoXx

Geht es hier um eine bestimmte Programmiersprache?

whitespacer schrieb:

sagen wir mal, wir haben eine Klasse "User". Diese Klasse hat die Attribute "Login" und "Passwort".

Nach dieser Beschreibung müsste die Klasse "UserCredentials" heißen.

whitespacer schrieb:

2. sollte man das Passwort auch trimmen oder lieber dem Benutzer eine Meldung ausgeben, dass ungültige Zeichen enthalten sind? Ich denke ja eher Letzteres.

Was sind denn zum Beispiel ungültige Zeichen?

whitespacer schrieb:

2. sollte man das Passwort auch trimmen oder lieber dem Benutzer eine Meldung ausgeben, dass ungültige Zeichen enthalten sind? Ich denke ja eher Letzteres.

Wozu das ganze? Wieso interessiert dich der Inhalt der Passwörter? Die können doch ruhig alles mögliche enthalten. Du übergibst sie doch eh einfach nur einer Key-Derivation-Funktion und die kommt damit schon klar.

Wenn du anfängst an manchen Eingaben herumzumängeln oder gar herumzufummeln, verärgerst du höchstens deine Nutzer. Insbesondere solche, die Passwortmanager o.ä. benutzen und einfach ein zufallsgeneriertes (oder von einem Masterpasswort abgeleitetes) Passwort ins Feld pasten.