Starší komentáře ke článku: Autorizace uživatelů v PHP
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 4.9.2001 7:33:14
PROČ se zaobirate resenim pro PHP3? Kdyz uz je davno venku ctyrka? Proc nevyuzit SESSIONS?
Ten clanek je uplne zbytecny, zastaraly. PHP4 lze snadno stahnout, vychazi na CD pocitacovych casopisu, takze je snadno dostupny. Freehostingove servery nabizeji take uz PHP4!
Nerozumim tomuhle zpatecnictvi.
Datum vložení: 4.9.2001 7:40:28
Nesouhlasim s Vasim nazorem ... SESSIONS je urcite dobra a uzitecna funkce (sam je pouzivam), ale pokud bych ji na strankach mel vyuzivat pouze k autorizaci, mozna bych se snazil vyuzit neco jednoduzsiho a mene narocneho ...
Datum vložení: 5.9.2001 8:55:41
ehm, ked sa vam sessions zdaju tazke, tak potom neviem...
Datum vložení: 5.9.2001 9:55:38
mel jsem na mysli neco mene narocneho na server ...
Datum vložení: 14.8.2004 17:46:05
Kdyz ma nekdo vypnute cookies.. dobre reseni
Datum vložení: 14.8.2004 17:57:57
Myslíte, že má nějaký praktický smysl komentovat tři roky starý názor? ;-)
Datum vložení: 8.9.2005 13:24:49
No to podle me opravdu nema ;-)
Datum vložení: 4.8.2006 22:24:06
jj fakt si myslim ze nema
Datum vložení: 13.9.2007 11:26:52
:D
Datum vložení: 25.2.2008 17:58:18
Taky si jeste po pul roce prihodim :)
Datum vložení: 16.6.2008 0:02:06
reagovat se má stále, ale hlavně se zdokonalovat
Datum vložení: 11.10.2008 16:06:47
:-)
Datum vložení: 20.11.2008 1:28:23
ja bych take nereagoval na stare nazory nema to smysl
Datum vložení: 24.4.2009 18:19:48
Je to kravina na entou:)
Datum vložení: 4.9.2001 7:35:07
Zajimave reseni :)) Diky ..
Datum vložení: 4.9.2001 19:23:53
Nechápu, proč autor zvolil takový způsob, místo toho, aby využil moderní a mnohem vhodnější sessions. Já je využívám na <a href='http://www.mitril.cz' target='_blank'>http://www.mitril.cz</a> a jsem absolutně spokojen. Pro zájemce - na <a href='http://www.reboot.cz' target='_blank'>http://www.reboot.cz</a> by měl do týdne vyjít článek na totéž téma, ale při řešení využívám sessions...
Datum vložení: 5.9.2001 9:34:49
Podle mě je toto řešení o něco bezpečnější, než pouze sessions. Nemohu ale mluvit za autora.
Sessions totiž fungují na tom principu, že se přidělí uživateli UID a toto číslo se po celou dobu relace nemění. Pokud si tedy toto číslo zapíšete i do svého řádku v prohlížeči (adresa?session_name=session_id), nebrání vám nic v tom, abyste měl přístup k otevřenému účtu apod.
Na článku mi ale nesedí jedna věc:
Na začátku se píše, že číslo ID udané v adresním řádku již není aktuální. To je ale podle mě nesprávné. Toto číslo je aktuální! Ale pouze pro toho, kdo jej použije jako první. Přitom není ošetřeno kdo to bude. Jestli jako první použije aktuální ID oprávněný uživatel se správnou IP (i když ani to není samospasitelné), nebo "šmírák".
Ale i tak je to bezpečnější, než použití sessions. Alespoň tak se jeví mě.
-Ladis-
Datum vložení: 7.9.2001 14:54:41
Předpokládám, že v době,kdy je již číslo (resp. celá adresa stránky) zobrazeno v adresním řádku, tak už je stránka načtena. A při načtení stránky skript automaticky vygeneruje nové číslo, které už je v databázi uloženo a správný kód je pouze v odkazech A-HREF a nikoli v adrese právě načtené stránky.
Uznávám, že se může adresa objevit již v průběhu načítání stránky, ale většinou se test autorizace uživatele stejně provádí hned na začátku, tak by se jednalo maximálně o nějaký zlomek sekundy u pomalého připojení.
Datum vložení: 5.9.2001 19:52:07
skript jsem prohlednul jen zbezne...ale tak me napadlo, kdyz ma pristup k pc vice lidi a daji tlacitko zpet tak si to klidne prohlidnou ne??Jak tedy udelat aby po odhlaseni zmizela historie navstiv. stranek u daneho serveru jako to ma email.cz ???
Datum vložení: 6.9.2001 23:07:09
jedine spolehlive reseni je zavrit okno prohlizece...<P>
jenom dodavam:
zajimavy clanek, nicmene v zadne autorizaci by nemelo chybet osetreni IP adresy. ani v teto, kdy klic se prubezne meni...
Datum vložení: 7.9.2001 14:58:29
Další řešení je dát na stránky tlačítko "Odhlásit", které např. uloží do databáze nějakou speciélní hodnotu. To ale ochrání jen ty uživatele, co se podstivě odlogují.
Dalším častým řešením je kombinace s časovou expirací.
Datum vložení: 27.10.2003 16:40:18
Nu myslim ze je nutnosti zákázat cache, pak když dáte zpět, id v URL předchozí stránky je už nepoužitelné...
Datum vložení: 12.5.2006 16:51:29
Pokud bychom brali v úvahu všechny metody využívané při kontrole vícenásobného přístupu, nabízela by se i IP Adresa. Tento způsob ale není možné využívat z jednoho prostého důvodu. Spousta uživatelů je schována za proxy serverem a tudíž je jedna IP Adresa společná například pro 10 uživatelů. Ojedinělé nejsou i případy, kdy pod jednou IP Adresou vystupuje celá škola. Pro zajímavost - toto řešení se chystá v blízké budoucnosti zavést i gymnázium, které navštěvuji. Pro kontrolu vícenásobného přístupu je tedy toto řešení dnes už nepoužitelné, protože žádnému serveru by na popularitě nepřidalo, kdyby v jeho anketě mohl hlasovat jen jeden člověk z deseti, či dokonce ze sta. A naopak - pokud by někdo naprogramoval a využíval autorizaci uživatelů pomocí IP Adresy, setkal by se s podobným problémem - pro uživatele se stejnou IP Adresou by nebylo problém tuto ochranu prolomit. Z tohoto důvodu není možné autorizaci využívající IP Adresu bezpečně používat.
Datum vložení: 12.9.2001 14:29:47
Ještě by to šlo vylepšit: neposílalo by se přímo heslo, ale nejdříve by se provedl hash hesla u klienta (JavaScriptem) a to by se odeslalo. Potom by se na jednotlivých stránkách předávalo zahashované heslo plus vygenerovaný kód. Čili přes Internet by ani heslo neputovalo.
Mělo by to ovšem háček, fungovalo by to jen při zapnutém JavaScriptu a ta funkce na výpočet MD5 by nebyla zrovna krátká, a přitom by se musela celá načíst. Ale když by šlo o extra security, bylo by to lepší.
Datum vložení: 12.9.2001 20:54:55
samozrejme, kdyz uz by o to opravdu slo, neni problem nabidnout dva zpusoby autorizace...mene bezpecnou a vice bezpecnou (js)
Datum vložení: 24.8.2002 15:46:57
Predstava, ze provedeni MD5 hashe hesla na klientovi a odeslani tohoto hashe, zvysi bezpecnost je podle meho nazoru <B>nesmysl</B>. Predstavte si ze jsem smirak, sedim nekde mezi vami a serverem, odposlouchavam komunikaci a hledam ten MD5 hash, poslany pres metodu POST. Najdu ho, zjistim si i login, a az se budu chtit prihlasit tak tyhle dva udaje poslu rucne (tj. nebudu hash hesla uz znovu "sifrovat"). Voila - poslal jsem spravny MD5 hash a login -> jsem nalogovany. Zvyseni bezpecnosti: nula.
Jedina slusna a bezne pouzivana ochrana proti odposlechnuti komunikace je SSL, i kdyz v podstate kazdou takovou metodu (kde si strany nejdriv musi vymenit klice po nezabezpecenem kanale) je mozno nabourat metodou "treti mezi." A to plati treba i pro SSH!
Datum vložení: 16.8.2002 21:14:56
MD5 via JavaScript existuje. Soubor je veliky cca 10k. BTW: Presne takto tj. javascript:MD5(heslo+salt) ---> net ---> PHP funguje autentifikace v mem projektu a je to dle meho nejbezpecnejsi varianta jaka existuje pro prenos hesla.
Datum vložení: 17.6.2003 8:42:27
Dobry den,
muzete me poradit? PHP + MySQL aplikace.
Do tabulky je ukladan login a dalsi udaje kodovane pomoci MySQL kryptovacich funkci encode a decode.
Stalo se, ze zvoleny login byl ulozen:
INSERT INTO users (jmeno, login) VALUES ('$jmeno', (encode('$login','$codpass')))
a nasledny vyber vratil 0.
SELECT jmeno FROM users WHERE (login LIKE (encode('$login','$codpass')))
Tato chyba se vyskytla pouze 1x (cca 100 zaznamu v db). Pro ostatni zaznamy pracuje bezchybne...
Nevite, kde je chyba?
Dekuji, Rucka
Datum vložení: 13.2.2004 14:09:42
hej hej.. a co ak uzivatel stlaci refresh stranky? odosle neplatne overovacie kluce a uz sa neprihlasi.. az po casovej expiraci..
Datum vložení: 13.2.2004 14:10:16
resp... musi sa znovu prihlasit...
Datum vložení: 14.2.2004 18:07:02
No, jasne, kdyz odesle refresh, tak se musi znova prihlasit.
Nejlepsi, co se da udelat, je hodit ho rovnou do prihlasovaci stranky
s vyplnenym loginem.
Datum vložení: 23.1.2006 13:44:38
Zdravim, viem, ze je to starsi clanok, ale rozmyslam nad zapracovanim podobneho systemu autorizacie a zaujalo ma, preco sa do DB uklada heslo a kluc, z ktoreho sa nasledne generuje kontrolny retazec. Preco sa neuklada rovno vygenerovany retazec? Aj tak ho nikto neuvidi a ak aj niekto nabura DB, tak ma uz predsa heslo, tak naco kluc? Alebo mi nieco uslo? :)) Dakujem.