ugrás a tartalomhoz

Javaslatok felhasználók regisztrálásához

ene · 2004. Május. 12. (Sze), 22.00
Javaslatok felhasználók regisztrálásához
Az egyszerű prospektus alapú webhelyektől eltekintve szinte nincs olyan oldal, ahol ne lenne felhasználó regisztrációra szükség. Sokan sokféleképpen közelítik meg az új tagok bevonására szolgáló felület és a háttérprogram kialakítását. Amikor egy felhasználót szeretnél regisztrálni, rengeteg mindenre kell(ene) odafigyelned. Ebben a cikkben ötleteket próbálok nyújtani, hogy hogyan a legcélszerűbb az adatokkal bánni, melyeket valószínűleg egy adatbázisban fogod tárolni, mivel a normál állományok nem elég biztonságosak. A PHP és MySQL kombinációja megfelelő eszközöket ad a kezedbe akár egy komplett portál megírásához is.

A regisztrációs űrlapot bontsd szét több lapra! A felhasználók nem szeretnek egy hosszú űrlapot kitölteni, jobban preferálják, ha először csak a legszükségesebb adatokat kérik be tőlük. Az első oldalon semmi mást ne kérj be tőle, csak a nevét, felhasználónevét és jelszavát! Az űrlapot elküldve generálj egy levelet, ami megerősítést kér a regisztrációról. A levélben csak a felhasználónév szerepeljen, jelszó semmiképpen sem. Ha a felhasználó a megadott módon megerősíti a regisztrációs igényt (amit a levélben kell elmagyaráznod neki), küldd el a jelszavát, amit generáltál, de a felhasználónevet ne! Ennek roppant egyszerű oka van. A levelek nem ritkán 5-10 szerveren is átmehetnek, mire a valódi címzett megkapja őket. Warez oldalakról ingyen letölthető programokkal szinte bárki elcsípheti a leveled. Ha a felhasználónév és a jelszó együtt szerepel egy levélben, semmi sem gátolja meg az illetéktelen behatolásban.

Következő lépésként léptesd be a felhasználót, majd adj neki lehetőséget, hogy megadjon magáról pár személyes adatot. Ha a portálod üzleti jellegű (például internetes bolt), tedd ezt neki kötelezővé. Ezt ne Javascripttel ellenőrizd, mert azt nem minden böngésző kezeli (verziója miatt, vagy esetleg le van tiltva). Használd erre is a PHP-t!

Az űrlapokkal van egy másik probléma is. Mit kezdj a ki nem töltött, de nem feltétlenül szükséges mezőkkel? A tartalma legyen "0"? Vagy netán ""? Inkább hozz létre egy külön cellát, amiben megadod, hogy a kérdést már megválaszolta-e! Ha nem, a következő belépésnél, vagy a saját adatait tartalmazó aloldalon tedd lehetővé, hogy megadja! Kérdezz rá, hogy a későbbiekben felhívhatja-e a figyelmét a kérdés megválaszolására, vagy nem. Ha nem, tedd lehetővé, hogy az adatait tartalmazó oldalon megválaszolhassa a kérdést, de külön ne zaklasd ezzel!

Térjünk vissza az előző problémához! Az illetéktelen belépést nem csak a felhasználónév és a jelszó nem egyszerre történő elküldésével tudod megakadályozni. Gondolnod kell arra is, hogy a te adatbázisodat próbálják meg feltörni. A jelszavakat ezért mindig titkosítsd! Használhatod az md5() függvényt is, vagy írhatsz saját titkosító algoritmust is. Utóbbit nem javaslom, mert nem tudhatod, hogy milyen karaktereket ad meg. Saját függvény használata esetén az algoritmusodnak pontosan meg kell egyeznie a megadható karakterek számával. Tehát ha csak az angol ABC betűit engedélyezed, akkor 2×26=52 (azért 2×, mert meg kell különböztetni a kis és nagy betűket is) karakterből kell állnia az algoritmusnak. Ha saját függvényt használsz, korlátozd a megadható karaktereket! Sose engedélyezd az ékezetes betűket felhasználónevekben és jelszavakban!

Fontosnak tartom azt is, hogy figyelmeztesd a felhasználót abban az esetben, ha a felhasználóneve és az e-mail címének @ előtti része (a postafiókjának azonosítója) megegyezik. Ha kalózkodni akarnék, elcsípném a jelszót tartalmazó levelet, és elsőként az e-mail postafiókjának nevével próbálnék meg belépni. Hívd fel a felhasználó figyelmét, hogy ez nem biztonságos, és adj lehetőséget a módosításra!

Hogyan továbbítsd az adatokat oldalról oldalra? Használj rejtett mezőket, vagy sütiket? Egyiket sem! A rejtett mezők egy idő után átláthatatlanok a programozás során, ráadásul ha félbehagyja az űrlap kitöltését, elvesznek az adatok. A sütik nem biztonságosak, ezért a munkamenetet kezeld sessionnel! Sütibe legfeljebb a session azonosítóját tedd, de azt minden oldalon ellenőrizd le! Ha nincs referrer, de van session, akkor a sessiont kézzel adta meg. Töröld a munkamenetet, és léptesd be!

Tekintsünk bele ennek formai megvalósításába!

A kérdéseket mindig ugyanabban a formátumban írd ki! Add meg, hogyan nézzen ki a kérdés, és mindig azt használd! A piros színt (#FF0000) lehetőleg ne használd, mivel ha a felhasználó színvak, nem fogja látni! Használd helyette a #FF3333-at! Ezt színvakok is el tudják olvasni, és piros a színe. Az űrlapot igényesen rendezd, használd a megfelelő cellaformázó parancsokat!

Ha az oldalad megkívánja, adj lehetőséget rá, hogy a felhasználód fényképet töltsön fel magáról! A feltölthető fájl méretét és típusát korlátozd! Ha csak fényképet engedsz feltölteni, korlátozd JPG-re és GIF-re a feltölthető fájlokat, és a mérete ne lehessen nagyobb 1000 Kbyte-nál. A képeket tárolhatod MySQL-ben is, de több értelmét látom, ha csak egy fájlnevet raksz az adatbázisba, a képeket egy külön, biztonságos könyvtárba helyezed. A getimagesize() függyvénnyel ellenőrizd a kép méretét, ha szükséges, készíts róla thumbnailt PHP-vel!

Az adatokat mindig ellenőrizd! Ne engedd, hogy betűt adjon meg, ha csak számokat tartalmazhat a mező, és fordítva. Vizsgáld meg, hogy a szükséges adatok valóban meg vannak-e adva, és azok helyesek-e (pl.: e-mail cím). Ha hibaüzenetet adsz bármilyen okból, az adatokat tartsd meg az űrlapban, de a hibásakat jól láthatóan jelöld meg és magyarázd el, mi velük a probléma. Sokan hagynák ott az oldalt, ha a figyelmetlenségük miatt újra ki kéne tölteniük az űrlapot. Adj lehetőséget a felhasználónév kivételével minden adat megváltoztatására, de ha az e-mail címét módosítja, ellenőrizd egy levéllel, hogy a cím valóban az övé-e. Generálj egy linket, amivel érvényesítheted az új e-mail címet! Csak a hitelesítés után tárold véglegesen az új e-mail címet.
 
1

Na és a felhasználóbarátság? :)

T.G · 2004. Május. 13. (Cs), 10.46
Sok jó gondolat elhangzott itt, de... :)

JavaScript:
Nincs annál rosszabb, mint amikor valaki a formokat nem ellenőrzi le kliens oldalon IS.
- nem adtad meg az emailcímed
- hibás emailcímet adtál meg: aésdklfjasdf
- nem adtad meg a születési időpontot
- valószínű hibás időpontot adtál meg: 1111 11 11
Na, amikor ötödször kapom meg azt a formot, amit egyszer sem akarnék kitölteni, de valamiért rámerőszakolnak, akkor én elhagyom az oldalt. Röhelyes, hogy nagyon sok portál regisztrációhoz köti azt, hogy olyan dolgokat letöltsek, amiket máshonnan is letölthetnék... De mindegy, ha kell a regisztráció akkor kell, de akkor legalább legyen felhasználóbarát.
Tessék JavaScripttel ellenőrizni, utána természetesen szerver oldalon is.

Ékezetes nevek:
Ha szeretnék ékezetes nevet magamnak akkor miért ne használhatnék? Én bajom, ha esetleg egy olyan terminálnál leszek, ahol nincs ékezet, de valószínű nem kerülök ilyen terminálhoz, tehát hadd használjak ékezetet.
Szerintem jelszavaknál is engedni kell az ékezeteket.
Ha valaki felhasználóbarát szeretne lenne, akkor jelszó ellenőrzésnél az y és z betűket is meg lehet nézni. Ha azt a jelszót írja be a juzer, hogy "sziaszia" és ez nem jó, akkor megnézem a "syiasyia" jelszót is.
Ezzel csökentem a biztonságot? Lehet, de nem zavar. :)

Üres mezők:
Biztos, hogy nem mindegy, hogy egy mező azért üres, mert nem töltötte ki, vagy kitöltötte és a kitöltés üres? Bár ez valószinű a konkrét esetben lehet eldönteni...

Színek:
Erről még nem hallottam, de érdekelne. Tudnál valami infót adni, hogy miért kell FF0000 helyett FF3333 használni? Pont fordítva gondolnám. :)

Képformátumok:
Na és a png? :)
2

Re: Na és a felhasználóbarátság? :)

ene · 2004. Május. 13. (Cs), 22.47
en a js-el semmikeppen sem ertek egyet. utalom a js-t. es meg lehet js nelkul is orizni az adatokat.

en nem nagyon szeretem ha ekezetet is hasznalnak, bar a mostani oldalamon nincs tiltva.

az y es z dolgot nagyon nem tartom jo otletnek :)

szin: az FF3333 egy olyan kevert szin, ami az RGB minden szinebol tartalmaz egy kicsit, ellentetben a sima pirossal. van olyan szinvaksag, amivel a piros szint nem latja. ha pedig pirossal irod ki a figyelmezteto szoveget, az illeto _semmit_ nem fog latni.

png: a png nagyon jo, de nem minden esetben. pl ha attetszo kep kell, a png kiesett, maradt a transparent gif. de hangsulyozom, a png _tenyleg_ jo, surun hasznalom en is :)
3

Re: Na és a felhasználóbarátság? :)

Bártházi András · 2004. Május. 13. (Cs), 23.19
Miért utálod a JS-t? Semmi baj vele. Csak nem kell olyan oldalakat építeni, ami *csak* JS-sel működik. A kliens oldali űrlap ellenőrzés, ha szerver oldalival is társul, és normálisan, szabványosan, minden böngészőn működően van megírva, teljesen jó megoldás.

Akkor lenne igazad a színnel kapcsolatosan, ha az FF0000 mellett a háttér fekete lenne. Ha az FF0000-t 000000-nak látja, egy FFFFFF -> 00FFFF színű oldalon, akkor tökéletesen látható marad számára. Bár én nem értek hozzá...

PNG-ben mind átlátszó (lyukas), mind áttetsző képeket lehet csinálni. GIF-ben csak átlátszót. Az IE elvileg nem bírja a PNG-t sajna, de egy kis trükkel rá lehet bírni. A PNG-vel nekem egyetlen bajom van, hogy nagyobbra szokott kijönni, mint a GIF, vagy mint a JPG.

-boogie-
5

Re: Na és a felhasználóbarátság? :)

ene · 2004. Május. 19. (Sze), 18.04
azert utalom, mert urlapok ellenorzesere felesleges, es hasznalhatatlan. leblokkolja, es maris annyi neki. akkor meg minek. jo, nyilvan egy 2000 hit / perc forgalmu szerveren kell, mert a vas nem birja ki, de egy atlagos latogatottsagu oldalnal szerintem felesleges. nem vagyok hive a js menuknek sem, tehat szamomra erdektelen. persze aki akarja, hasznalja, de ne epitsen kizarolag js-re, mert porul fog jarni.

tok mindegy milyen a hatter, ha a pirosat nem latja :)

tudom, hogy lehet, de az IE alapban nem kezeli. bar van ra hack.
6

Re: Na és a felhasználóbarátság? :)

Bártházi András · 2004. Május. 19. (Sze), 22.12
Szerintem pedig kényelmessé tud tenni egy plusz kliens oldali ellenőrzés egy kitöltést. Az illetőnek nem kell várnia egy lassú kapcsolat esetén, hogy újra letöltődjön az oldal, hanem egyből kap egy visszajelzést. Tehát ez egy kényelmi szolgáltatás.

Abban teljesen egyetértünk, hogy ne építsen senki se kizárólag JS-re. :) Csak ne ítéljünk el egy jó megoldást elhamarkodottan.

Amit a piros színre írsz, az hülyeség. Olyan nincs, hogy nem lát valamit. Ha nem látja, akkor feketének látja. Vagy másmilyen színűnek, nem értek hozzá. Az a lényeg, hogy ne legyen egymás mellett két olyan szín, amit ugyanolyannak lát. Szóval kérnék egy linket ahol ez le van írva, mert így nem vagyok hajlandó elhinni...

-boogie-
7

Re: Na és a felhasználóbarátság? :)

ene · 2004. Május. 23. (V), 14.13
igazad van, utannaneztem ismet, en emlekeztem rosszul. valoban csak mas szint lat (meghozza szurke)
4

JS nélkül?

T.G · 2004. Május. 14. (P), 23.48
Abban igazad van, hogy js nélkül is lehet honlapot építeni, de ez nem jelenti azt, hogy nem kell használni. :)

Kedvenc példám, ami egyelőre sajnos csak béta verziónál tart:
http://hu2.php.net/search.php
Az itt lévő kereső kiegészítő valóban addig nem hiányzik, amig nem láttam, de azóta mióta itt Goba megmutatta, ez az oldal is a kedvencek között van. :)
8

Referrer nem biztos, hogy van!

nagykutya · 2004. Május. 28. (P), 15.20
"Ha nincs referrer, de van session, akkor a sessiont kézzel adta meg. Töröld a munkamenetet, és léptesd be!"

A http://hu.php.net/reserved.variables oldalról az idézet:
"The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted."

Ehhez még hozzátenném, hogy pl. a Norton Internet Security alapbeállításnál törli a referrert, nem engedi át mint személyes adatot (meg sok mást sem), úgyhogy ez szerintem elég rossz ötlet.
9

Referrer

Anonymous · 2005. Már. 23. (Sze), 22.54
Hát... nem csak URL-be kéne átvinni a SID-t hanem regisztrálni valami sessionra érvényes globálist, és azzal