Diskuze: Identifikační klíč uživatele a ověření
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Člen
Zobrazeno 19 zpráv z 19.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj,
jen pro ujasnění - když bude uživatel registrován, pak to můžeš
zjistit pomocí session. K čemu potom chceš předávat tuto informaci přes
URL?
V podstatě pokud bude existovat ID uživatele v session, pak se jedná o
přihlášeného uživatele.
Stále moc nepobírám smysl toho předávání v URL. Co když přijde neregistrovaný, v URL bude mít n1, n2 a přepíše si to na r1 a r2? Stejně pak budeš muset dělat nějaké kontroly, jestli to r1 a r2 je správně (tzn. jestli je uživatel přihlášen).
Plácnu teď...
Když vyvolám URL
http://neco.cz/?p=n1
http://neco.cz/?p=n2
Každý ID vlastní jiný neregistrovaný uživatel. Když si vyvoláš tento odkaz např n1, ukáže se ti jen web a obrázek s popisem..To samé u n2.
Pakliže se rozhodneš to upravit, tak jsi nucen zadat údaj, který jsi zadával při vkládání obrázku, tedy heslo. Samozřejmě se to uloží do SESSION a můžeš v klidu editovat -> upravit, smazat atp...
Možná je to zbytečné že to vůbec řeším, ale přeci jen více hlav a více názorů
V tom případě nemusíš žádný N ani R řešit. URL bude jako unikátní ID, nebo třeba SEF. Použitím POST by sis v tuhle chvíli docela protiřečil.
Jinak pokud bych musel zadávat email a heslo, není to už potom v podstatě rychlá registrace? Napadá mě například povolení editace podle IP. Jestli jde o nějaké zveřejňování nápadů (z toho nahoře jsem to tak pochopil), mělo by to v pohodě stačit.
SEF? S tímto jsem se ještě nepotkal...
Byly by 2 databáze neregistrovaný a registrovaný. Takže bych krásně věděl odkud data tečou.
SEF je označení pro (konkrétně v tomto případě, je to s tím složitější) jakýsi identifikační název "přátelštější" jak pro uživatele, tak pro vyhledávače. Například "dk83jdi13" => "kuchyne/lednice/super-levna-lednice".
Dvě databáze určitě ne. Nemyslíš spíš dvě tabulky? Nevidím důvod používat dvě databáze.
Popravdě řečeno, není to úplně to co jsem uvedl. Každopádně nerad bych uváděl skutečný nápad. Je pravda, že by to šlo řešit i bez té mini registrace (email, heslo) ale mělo by to značné omezení. Možná by to šlo řešit jen tím klíčem v emailu k editaci (což by mohlo být lepší) Tím bych zrušil jakýkoliv náznak nějaké mini registrace i když přímé registrování ponese více iniciálu z důvodu nutnosti k některým věcem. Samozřejmě tohle až tak úplně neřeší pravou pointu toho co řeším i když rozhodně děkuji za zmínění, aspoň mě napadlo nové řešení. Proto také jsem založil toto vlákno, pak člověka napadne spousta jiných věcí.
Ano 2 tabulky... Nějak to stále popisuji jako databázi(špatný zlozvyk).
Teď docela dobře nevím, na co vlastně řešení hledáš. Můžeš to vysvětlit ještě jednou, trochu konkrétněji?
Dobře...
Budu/chci mít 2 skupiny ->
Ty fotky se nahrávají proto, aby je mohli prezentovat a kdykoliv sdílet. Samozřejmě ne jenom ten kdo to nahrál, ale třeba i někdo cizí, nebo kamarád.
Osobně(Já) abych věděl odkud data proudí co nejjednodušeji, tak si vytvořím 2 tabulky pro každou tu skupinu.
Neregistrovaný
(Již s menší změnou než prvně).
*ID -> ID bych vygeneroval klasicky unikátním ID v Mysql , ID by tedy
sloužilo jako identifikace neregistrovaného uživatele i pro veřejné
zobrazení obsahu, tedy nahraného obrázku včetně popisu atp..První
uživatel by měl tedy ID: 1 s dosazením pro třídění písmeno "n" takže
identifikace a URL pro načtení by mohla vypadat např takto: http://něco.cz/n1 ... později
třeba http://něco.cz/n8582154581
OTÁZKA: Řešili by jste identifikaci, nějak lépe, nebo je postup
špatně? Názor !
OTAZKA: Jiný nápad na generování klíče pro aktivaci zobrazení?
OTAZKA: Jak by jste řešili generování unikátního klíče pro editaci neregistrovaného uživatele v URL
Registrovaný uživatel řeší stejnou otázku s ID. Takže nestojí za zmiňování.
A je nutné řešit editaci pro neregistrovaného uživatele? Samozřejmě to jde, kdyby ale byla editace jedna z výhod pro registrované uživatele, bylo by to nejen jednodušší, ale i bezpečnější.
Jinak si to můžeš hodit do jedné tabulky, jen ti přibude sloupeček.
Identifikace špatná určitě není, možná by ale bylo lepší použít nějakou šifru/hash, což by znamenalo minimální ochranu obrázků.
Pokud budeš používat nějaký známější hash (MD*, SHA-*, atp.), aktivační kód by si dokázal vygenerovat každý, kdo má přístup k emailové adrese uživatele. Otázkou je, zda-li je to problém.
Moje řešení: neregistrovaný uživatel přes formulář nahraje obrázek s tím, že zapíše svou emailovou adresu. Na ní se pošle unikátní klíč pro editaci. Do databáze se uloží i speciální ID, které se bude používat pro další obrázky pod tímto emailem. Také by sloužilo jako ID do URL.
Registrovaný uživatel by fungoval stejně, jen by byl prostě registrovaný, tudíž toto ID by se vytvořilo už při registraci.
Řekl bych, že je to docela elegantní řešení, možná ale pořád špatně chápu funkci webu, když tak povídej.
Děkuji, přesně takovou odpověď jsem potřeboval.
Editace pro neregistrované není úplně nutná, ale bude to lepší.
S řeším: Takto, nebo dosti podobně to vidím také.
Jestli jsem ti pomohl, prosím o stisknutí takové té fajfky (řešení). Docela mi to pomůže. Klidně si ale počkej, třeba někdo přispěje lépe než já.
Vzhledem k tomu, že jsi mě tak nějak utvrdil v řešení. Zároveň pochybuji, že by to někdo četl, když se jedná o tolik textu. Tak ti fajfku dám tedy hned. Dostal by jsi ji stejně, jen ne tak rychle. Chodím sem často a kromě 1 článku jsem dal řešení vždycky
Zobrazeno 19 zpráv z 19.