Strona główna> Blog practice>Co wolno, a czego nie wolno – czyli walidacja formularzy rejestracji.

07.201407

form_validation

Co wolno, a czego nie wolno – czyli walidacja formularzy rejestracji.

Jedną z najważniejszych funkcjonalności większości stron internetowych i dużej części innego software’u jest możliwość rejestracji użytkowników. Jak sprawdzać, czy dane wprowadzono poprawnie? Jakich ograniczeń użyć? Jak wybrać dozwolone znaki? Z pozoru proste pytania mają ogromny wpływ nie tylko na funkcjonowanie oprogramowania, ale także zadowolenie klienta.

 

Użytkownik, co do zasady, sam zakłada konto. Czasem robi to za niego administrator. W każdym przypadku największym wyzwaniem jest sprawdzenie poprawności danych. Nie trzeba tłumaczyć, jak ważne jest dla właściciela oprogramowania, aby przechowywać prawidłowe dane.

 

W zależności od przeznaczenia oprogramowania istnieją różne pola obowiązkowe i opcjonalne. Skupimy się jednak na standardzie obrzydliwym, czyli najważniejszych polach formularza rejestracji na stronie internetowej: Imię i Nazwisko, email, nazwa użytkownika, hasło. Jeśli jesteś ciekawy dlaczego radzę tak, a nie inaczej, zapraszam do lektury.

 

1. Przedstaw się, przede wszystkim.

 

Pole ‚Imię’ i ‚Nazwisko’. Czasem prezentowane razem, częściej rozdzielane. Czy może być problematyczne? TAK!

 

dsadsadasdas

(tłum. Ubiegałem się o stypendium dopóki nie napotkałem na błąd „nazwisko musi być dłuższe niż 2 znaki”)

 

 

- Dopuszczaj wszystkie litery, litery z akcentami, cyfry. Warto rozważyć, czy będziesz używać alfabetów innych niż łaciński.

Świat stał się globalną wioską, a internet nie znosi granic. Jeśli planujemy stworzyć ogólnodostępny serwis można zastanowić się, czy gość z Rosji nie zechce użyć grażdanki. W przypadku cyfr należy dopuścić je z dwóch powodów. Po pierwsze np. w Stanach Zjednoczonych możliwe jest nadanie dziecku imienia cyfrą, np. „5”. Istnieją takie przypadki… Po drugie imiona afrykańskie mogą zawierać akcenty pisane w postaci cyfr, tak samo jak transkrypcje arabskie.

 

- Dopuszczaj znak apostrofu.

W Irlandzkich, czy szkockich nazwiskach często znajdujemy apostrofy, np. O’Donell

 

- Minimalna ilość znaków? Jeden! (patrz zdjęcie wyżej)

W Chinach ludzie otrzymują niekiedy imię od nazwy wsi. Istnieją wioski, które po transkrypcji brzmią na przykład tak: „U”.

 

- Maksymalna ilość znaków? Co najmniej 30 dla imienia oraz 30 dla nazwiska.

Czy słyszałeś o Hubercie Blaine Wolfeschlegelsteinhausenbergerdorff’ie? To jego skrócone nazwisko… Łatwo sobie wyobrazić, że miał problem nie tylko z wyrobieniem karty kredytowej. Komputer IBM 7074 przetwarzający polisy ubezpieczeniowe nie potrafił sobie poradzić z jego nazwiskiem. Jeśli prowadzisz zwykły sklep internetowy, trzydzieści znaków wystarczy każdej pani z poczty. Jeśli chcesz jednak wysyłać listy do UK to pamiętaj, że tamtejszy urząd zwróci przesyłkę nawet, gdy jedna litera będzie w niewłaściwym miejscu.

 

2. Adres do świadczenia usług drogą elektroniczną.

 

Czyli po „polsku” mejl. Czy tu sprawa wydaje się prosta? Nie do końca. Wiele rzeczy zmieniło się w poczcie elektronicznej, jednak programiści nie zawsze zdają się te zmiany dostrzegać.

 

- Przede wszystkim dopuszczalne znaki. Warto się nad tym zastanowić. Większość z nas od razu założy, że dopuszcza wszystkie litery bez akcentów oraz cyfry. Co dalej? Czy kropki są w porządku. Podkreślenia i minusy chyba też? Co z innymi znakami? Standardy RFC do,puszczają w części lokalnej adresu email całą tabelę ASCII, a standard RFC 6531 opisuje dodatkowe znaki.

Dlaczego kłopotać sobie głowę znakami specjalnymi? Przede wszystkim ze względu na Google. Jako jeden z największych dostawców usługi poczty elektronicznej dopuszcza on kropki i plusy. Wielu użytkowników korzysta z tej funkcjonalności, aby porządkować swoją pocztę. Na przykład „user+shop@gmail.com‚; „user+social@gmail.com”; Wszystkie maile spłyną do użytkownika „User”. Swego czasu AOL pozwalał użytkownikom używać takich znaków jak „%”. Można by mnożyć przykłady. Lista dopuszczalnych znaków znajduje się we wspomnianym RCC 6531. W artykule na wikipedii zostało to uporządkowane w punkcie „Syntax”.

 

- Jeśli chodzi o długość adresu odpowiedź jest bardzo prosta. Określają ją standardy dla protokołu SMTP. Adres nie może być dłuższy niż 254 znaki. Część lokalna (część-lokalna@) nie może być dłuższa niż 64 znaki.

 

- Adres email nie może występować w systemie wielokrotnie.

 

3. Nazwa użytkownika.

 

- Kwestia nazwy użytkownika pozostaje zawsze w gestii tworzącego portal. Warto zastanowić się, czy nie będziemy używali formatu imię_nazwisko, wtedy sugeruję walidację podobną do pól… „Imię” oraz „Nazwisko”! Warto przede wszystkim pamiętać, żeby nazwa użytkownika składała się co najmniej z jednego znaku oraz była niepowtarzalna.

 

4. Hasło.

 

- Przede wszystkim bezpieczeństwo! Wymagaj! Co najmniej 8 znaków w tym litery i cyfry.

Dlaczego akurat 8 znaków? Odpowiedź znajdziemy w większości serwisów zajmujących się bezpieczeństwem. Chodzi o szybkość z jaką może zostać złamane hasło przy ataku brute force w zależności od ilości i kombinacji różnych znaków. Poniżej przykład dający do myślenia.

Tabela opracowana przez firmę KROLLONTRACK.

Tabela opracowana przez firmę KROLLONTRACK.

 

- Dobrze sprawdzić, czy hasło jest różne od nazwy użytkownika i lokalnej części adresu email.

 

- Czego nie należy robić? Ograniczać fantazji użytkownika… do pewnego stopnia. O ile 200 znaków może być na wyrost, to nie wymagajmy, aby hasło składało się DOKŁADNIE z jakiejś ilości znaków. Ten system walidacji wybrał sobie na przykład DeutscheBank, o czym już pisaliśmy.

 

- Niedozwolone znaki? Teoretycznie możesz pozwolić na wszystkie znaki, które będziesz w stanie poprawnie przechowywać zahashowane w bazie. W praktyce warto stworzyć katalog zamknięty znaków, które będą dozwolone.

Czy zastanawiałeś się kiedyś jak wpisać hasło, którego częścią jest tabulator? Zdarzyło mi się kiedyś za namową kolegi skopiować tabulator z edytora tekstu, a następnie wkleić go do mojego nowego hasła. Łatwo sobie wyobrazić co się działo, gdy wpisywałem hasło w formularzu logowania… Po prostu przeskakiwałem do kolejnego elementu…

 

5. Puszka Pandory

 

- O ile „$” i „%” mogą być niepokojące, to prawdziwą puszkę pandory otwierają dwaj posłannicy piekieł: „<” oraz „>”.

Czemu trójkątne nawiasy są takie straszne? Nie jeden raz zdarzyło mi się testować stronę, której formularze akceptowały html… Choć można się z tego śmiać pod nosem i traktować jako barową opowiastkę, warto dmuchać na zimne. Najłatwiej zastrzec trójkątne nawiasy w każdym formularzu. Uwierzcie lub nie, usuwanie fotografii longcata z nazwy użytkownika nie jest niczym zabawnym.

 

Czy myślicie, że to wszystko, o czym należy pamiętać? Może znacie jakieś przykłady z życie, które warto byłoby uwzględnić?

Pola adresu, nazwy firmy czy numeru kontaktowego zostaną omówione w kolejnym artykule o walidacji formularzy zamówień.

testowanie oprogramowania | outsourcing testów | software testing | testerzy