ugrás a tartalomhoz

Regisztráció megerősítése hogyan működik?

montressor · 2006. Aug. 28. (H), 12.13
Hala!

Nem tud vk. linket, cikket regisztracio megerositesenek megvalositasarol?
Tehat ami a legtobb siteon van: a rendszeer most elkuldott neked egy emailt, abban: erre es erre a linkre kattintva: sikeresen aktivaltad a regisztraciot... Bar, ha jobban belegondolok, nem tudom eletkepes megoldas-e, ha regeleskor az emailben egy "blabla.hu?user=bela%aktivalokod=generaltszam"

linket vesek, az ipse rakkattint es en csak osszenezem, h letezik-e mysql-ben a bela-hoz a generalt szam?
Koszonom
‹ MVC tervezési minta a gyakorlatban Kideríthető melyik fájl include -ja az adott fájl? ›
 ■
1

Sok módszer létezik

w3net · 2006. Aug. 28. (H), 13.12
egy a sok közül:
kigenerálsz egy egyedi karakterláncot pl. igy: MD5(time . IPcim).
Ezt elmented az adatbázisban. Majd ez e-mailben elküldöd neki az aktivációs linket, aminek a végére ez a kis egyedi kód lesz hozzáfűzve (pl: http://mysite.xx/activation.php?id={egyediaznosito}. Az aktivációs linkre kattintva a PHP szkript megeresi az adatbázisban a megfelelő rekordot, és átirja a dateActivated oszlop értékét az aktuális dátummal. A lényeg az, hogy kell egy jelző, amivel tudod, hogy ez a felhasználó már aktiválta a tagságát. Én a dateActivated nevet adnám ennek a jelzőnek (adattipusa unsigned int lenne és Unix timestamp érték kerülne bele aktiváláskor).
2

inkább külön tábla

breakline · 2006. Aug. 28. (H), 18.13
sokkal egyszerűbb:

regisztrációkor belerakod egy külön táblába USERID - KOD párban. Mikor be akar valaki jelentkezni, megnézed, h bent van-e ebben a táblában az adott USERID, és ha igen, nem engeded bejelentkezni.
Ha aktivál, akkor simán kitörlöd a táblából.


BL
3

Miért egyszerűbb?

fchris82 · 2006. Aug. 28. (H), 18.53
Nem gondolom, hogy a két táblás megoldás jobb. Ugyanúgy a felhasználóhoz tartozó tulajdonság az, hogy aktivált felhasználó vagy sem! Ez olyan, mintha külön táblában tárolnád a címét, a jelszavát, ... . Felesleges.
Hozzácsapsz egy oszlopot, oszt annyi :) De ezért külön tábla? Ráadásul egy (egyszerű és áttekinthető) lekérdezéssel megvan a belépés:
SELECT user_id FROM users WHERE user_name='un' AND user_psw=PASSWORD('psw') AND activated=1
Míg a te esetedben két táblával kell szórakozni feleslegesen.
4

több megoldás

breakline · 2006. Aug. 28. (H), 19.07
gondolom ezért írta az előttem szóló h több megoldás van:)
De ha külön táblában tárolod:
kevesebb adatot tárolsz. (csak azok szerepelnek a táblában, akik még nem aktiválták magukat)
azt én két különböző tulajdonságnak tartom, hogy egy felhasználó aktív-e, vagy aktiválta magát. Az aktív/passzív többször változhat, ez esetben egy felhasználó csak akkor szerepel a táblában, amikor regisztrál, később oda nem kerül vissza. Az admin később letilthatja a felhasználót, ezt persze a felhasználók táblájában tárolja.
Na mindegy, én csak ugy találtam h ez egyszerűbb.

BL
5

A két tábla védelmében

vbence · 2006. Aug. 29. (K), 12.49
A kéttáblás megoldás abban jobb, hogy a "valcode" oszlopra csak egyszer van szükség, amikor az illető regel (esetleg később elfelejtett jelszónál, de akkor úgy is újat generálsz). Miért tárolnád a user táblában a több éve aktualitását vesztett kódot? Sok usernél ez sok hely... (Én nem csak a vinyón, hanem a cache-ben is.)

Másrészt pedig ha picit finomítod a rendszert, akkor a kódnak lehet egy élettartama is (pl 48 óra). Ez egy újabb mező, ami szintén csak addig érdekes, amíg meg nem történt a visszaigazolás.

B
6

Esetleg...

PER · 2013. Jan. 23. (Sze), 23.23
Ha spórolni akarsz, akkor nem kérsz jelszót regeléskor.
Kiküldöd az aktivációs emailt és akkor adja meg.
Ez db oldalról úgy nézne ki, hogy addig nem aktivált, amíg nem adott meg jelszót:)
Ezt lehet még kombinálni azzal, h jelszónál alapból kódolatlanul pl: "!aktiválásikód!".
Amikor kódoltan eltárolod a jelszót, akkor ugye az már nem tartalmazhat pl. "!" jelet. Így nem tudod keverni. Így egy teljes attribútumot ki tudsz spórolni, persze cserébe lesz pár sor bonyolítás a kódban:P
7

DB nélkül

joed · 2013. Jan. 23. (Sze), 23.54
Én újabban a "meghívó" stílusú aktiválást használom. Ennek az a lényege, hogy nem a regisztráció után, hanem az előtt történik az e-mail cím megerősítése. Így nincs szükség semmilyen adat tárolására, ami adatkezelési/jogi szempontból kifejezetten előnyös. Azért hívom meghívós módszernek, mert gyakorlatilag a regisztrációval első lépésben saját magának küld egy megerősítő kódot tartalmazó meghívót. A kód valójában egy MAC, amit az e-mail cím aláírásából kapunk.
pl: 

http://example.com/registration/complete?email=john##kukac##doe.net&code=b37993ffc30aad9579fcc3cc8ac6fa30eb56344e
A MAC-et ki-ki szájíze szerint előállíthatja az e-mailből: hozzácsapsz egy salt-ot/kulcsot vagy választasz egy jó kis algót és azzal hash()-eled.
Amikor visszajön az illető, csak ellenőrizned kell a MAC-et és ha stimmel, mehet is a regisztráció.
8

Tetszik, megjegyzem:)Így

Gl3am · 2013. Jan. 24. (Cs), 00.25
Tetszik, megjegyzem:)

Így nincs szükség semmilyen adat tárolására, ami adatkezelési/jogi szempontból kifejezetten előnyös.


De ha nem igazol vissza akkor akár pár órán belül törlődik, így "adatkezelési/jogi szempontból" milyen aggályaid vannak? Na meg így is tárolod az email címét, akkor meg nem mindegy? Nem tudom, kérdezem:)

[Szerk.]
Közben leesett, hogy nincs szükség az email cím tárolására.

PER: Ez egy 2006-os téma:)
9

Srácok,

Pepita · 2013. Jan. 24. (Cs), 02.19
egy darab int oszlop azért nem a világ (plusszban). Mondjuk én ugyanezt használom többféle státuszra is. A jogosultságok kezelésére (ha van ilyen) kell másik (két) tábla, hogy a Júzer több felh. csoportnak is tagja lehessen, de a kiküldött kódra elég 40 karakter, amiért kár +1 táblát karbantartani, valamint u.ezt használod elfelejtett jelszóra is.
Tárolni meg azt tárolsz róla adatot, amit akarsz, DE! kellő képpen tájékoztatnod kell, hogy pontosan mit tárolsz és miért, valamint ezen tárolás elfogadásakor regelhet csak (checkbox, nem előre bepipálva).
Szerintem nem szeretik, ha többszöri lépésben tudnak csak regelni, -> nem kötelező regeléshez az e-mail-link, ha kamu e-mailt adott meg, majd megszívja később.

(Attól, hogy 2006-os, még továbbfűzheti, ha kedve tartja.)
10

Nem értem a hozzászólásod

Gl3am · 2013. Jan. 24. (Cs), 10.32
Nem értem a hozzászólásod miértjét.
joedtől annyit kérdeztem, hogy neki milyen aggályai vannak adatkezelési/jogi szempontból, ha egy nem visszaigazolt regisztráció néhány óra hosszára az adatbázisban pihen. Nem azt kérdeztem, hogy mit szabad és mit nem.
Azt meg végképp nem értem, hogy miért nekem címzed, hogy egy vagy két táblát használjak, abban a szálban abszolút nem vettem részt.:)
12

az idő kérdése

joed · 2013. Jan. 26. (Szo), 15.07
Az említett módszer okosan bővebb adatok ellenőrzésére is alkalmas. Például az e-mailben kiküldött URL-be egy dátumot is elhelyezel és a dátumot belevonod az aláírásba. Tehát összefűzöd az e-mailt és a request dátumát, majd ebből készítesz MAC-et. Természetesen bármennyi paraméterre/adatra alkalmazható, de egy idő után az URL-ed elég csúnya, hosszú lehet.
11

adatkezelés

joed · 2013. Jan. 26. (Szo), 15.01
Amint személyes adatokat kezelsz, meg kell felelned bizonyos jogszabályi követelményeknek (lásd. 2011. évi CXII. törvény).

Röviden a lényeg, hogy amíg személyes adatokat tárolsz kötelezettségeid vannak, amelyek felelősséggel járnak. Ha nem tárolsz adatokat, nincs felelősséged. Ezért írtam, hogy célszerű minimálisra csökkenteni a nem használt adatokat, mert csak felesleges kockázatot jelentenek.