| Autor | Zpráva | ||
|---|---|---|---|
| sifik Profil |
#1 · Zasláno: 12. 8. 2011, 20:31:51
Spíše teoretická otázka. Odjakživa používám tento zápis:
$user_login = $_SESSION['user_login']; $user_pass = $_SESSION['user_pass']; A jak tak koukám na skripty ostatních či nějakých návodů, myslím, že rozhodně nejsem sám. Ale dnes jsem narazil na tento způsob ukládání dat do session: if (isset($_SESSION['auth'])){
$user_id = $_SESSION['auth']['id'];
$jmeno_auth = $_SESSION['auth']['jmeno'];
$hodnost = $_SESSION['auth']['hodnost'];
$time = $_SESSION['auth']['time'];
...Zajímalo by mě, zda tento způsob má nějaké výhody, či nevýhody od klasického. Popřípadě, zda se dá u moderních aplikací používat? Nebo jaké máte s tímto zápisem zkušenosti? |
||
| Joker Profil |
#2 · Zasláno: 12. 8. 2011, 21:01:09 · Upravil/a: Joker
sifik:
Jistěže se to používat dá. Jde spíš o určitý způsob organizace dat. Další možnost je ukládat si do session objekty, tj. třeba: $_SESSION["auth"]->id $_SESSION["auth"]->jmeno edit: Raději to ještě upřesním, v případě těch objektů nejde o „jiný způsob zápisu“, tj. místo pole si data naházet do objektu, ale o to, že s těmi objekty se pak dá dál pracovat jako s celky. |
||
| Johnik Profil |
#3 · Zasláno: 12. 8. 2011, 21:02:01
1) Určitě do session neukládej heslo.
2) Druhý způsob je lepší, že stačí ověřit, zda existuje session se jménem "auth". Tedy je to jakési zapouzdření uživatelova přihlášení. Ale je to skutečně úplně jedno. |
||
| johnl Profil |
#4 · Zasláno: 12. 8. 2011, 21:29:45
Johnik:
„1) Určitě do session neukládej heslo.“ Pokud vím, obsah session zůstane na serveru, pokud uživateli nedáš njakou možnost obsah vypsat, případně se uživatel nedostane „do serveru“, pak se k heslu v session stejně nedostane.. ;) |
||
| pcmanik Profil |
#5 · Zasláno: 12. 8. 2011, 21:30:49
johnl:
Ano, ale ma to nejaky vyznam tam to heslo ukladat? Kde ho este v aplikacii vyuzijes? |
||
| DoubleThink Profil * |
#6 · Zasláno: 12. 8. 2011, 21:53:01 · Upravil/a: DoubleThink
Session se serializuje do nešifrovaného souboru na serveru. Často dokonce do /tmp, kam má v kontextu systému přístup každý vometák. Ukládat heslo do session v nezahashované podobě je bezdůvodné snižování bezpečnosti aplikace.
|
||
| sifik Profil |
#7 · Zasláno: 13. 8. 2011, 09:31:29
Děkuji za vysvětlení.
Je pravda, že heslo v session nemá vůbec žádný smysl.... Identifikace uživatele se dá udělat různými způsoby... (Btw, zdá se vám, jako rozumný způsob, kdy při každým přihlášení vygenerujete uživateli unikátní klíč(token), který by pak sloužil místo hesla? Ten klíč by se uložil např do tabulky i s uživatelským jménem. Při každým "reload", by to kontrolovalo zda existuje v tabulce nějaký uživatel s daným "token", pokud ano vyzvedlo by to jeho jméno a pak by to zkontrolovalo, zda takový uživatel vůbec existuje. (jednoduše popsáno)) |
||
| Alphard Profil |
#8 · Zasláno: 13. 8. 2011, 12:07:59
sifik:
Možné to je, ale často se přihlášení zase tolik nekomplikuje. Pokud je pomocí session uživatel přihlášený, tak to při krádeži cookie s identifikátorem session stejně nepomůže. Hlavní výhoda (nebo nevýhoda?) je, že při novém přihlášení se uživatel odhlásí v dřívějším okně. |
||
| sifik Profil |
#9 · Zasláno: 13. 8. 2011, 14:51:25
Ať mám otevřeno třeba 5 panelů, či oken můžu pracovat ve všech najednou. Je to snad bezpečnostní chyba? Stejně jako, že při uzavření a následném otevření prohlížeče, jsem stále přihlášen a to hned v několika panelech?
|
||
| Joker Profil |
#10 · Zasláno: 13. 8. 2011, 14:59:07
sifik:
Ani v jednom případě není nutné držet heslo v session a v tom druhém případě na to session dokonce vůbec nemá vliv (resp. teoreticky je možné pamatování přihlášení řešit přes session, ale byl by to opravu extrémní případ a snad nikdo to nedělá). |
||
| DoubleThink Profil * |
#11 · Zasláno: 13. 8. 2011, 17:15:04
sifik:
„Btw, zdá se vám, jako rozumný způsob, kdy při každým přihlášení vygenerujete uživateli unikátní klíč(token), který by pak sloužil místo hesla?“ Ani ne. Stačí mít na paměti, že session je stejně (málo) soukromá jako databáze nebo soubor na serveru. Ani jedno z těchto tří úložišť by tedy nemělo obsahovat hesla uživatelů. Do session stačí uložit něco ve smyslu přihlášen = ano. |
||
| sifik Profil |
#12 · Zasláno: 13. 8. 2011, 18:12:54
Pokud do session uložím pouze informaci typu přihlášen = ano, jak pak následně ověřím, kdo je přihlášen? A jak pak může takhle přihlášený uživatel pracovat ve své administraci, když ani neví, kdo je? (není to uložené v session).
To vyvrací úplně vše, co jsem doteď vyčetl z literatury :) |
||
| johnl Profil |
#13 · Zasláno: 13. 8. 2011, 18:22:43 · Upravil/a: johnl
sifik:
Myslím že DoubleThink tím myslel že si do session uložíš např. jméno toho kdo je přihlášený - tím zjistíš kdo a jestli vůbec je přihlášený (a samozřejmě pár dalších potřebných údajů, ale heslo není potřeba.. :) ).. |
||
| o_O Profil |
#14 · Zasláno: 13. 8. 2011, 18:25:53 · Upravil/a: o_O
sifik:
„Pokud do session uložím pouze informaci typu přihlášen = ano“ To bylo k tomu tokenu. Já osobně vytvářím pole, kde ukládám ID uživatele, potřebné věci (např. nick, práva, ...) a pak IP, kterou kontroluji při každém načtení stránky (jednoduše: jiná IP = krádež cookie = odhlášení) |
||
| Joker Profil |
#15 · Zasláno: 13. 8. 2011, 18:38:23
sifik:
„Pokud do session uložím pouze informaci typu přihlášen = ano, jak pak následně ověřím, kdo je přihlášen?“ DoubleThink to asi nemyslel tak doslova. Prostě se do session uloží ID přihlášeného uživatele, což je zároveň ta informace, že je přihlášen. Neboli bude přihlášen = id, přičemž informace přihlášen = ano je uložena v tom, že to „přihlášen“ není prázdné. I když v některých aplikacích by to šlo realizovat i přesně tak jak píše DoubleThink. Například aplikace vůbec nemusí mít uživatele, ale jen administrátorské heslo. Pro vstup do administrace stačí zadat heslo, případně filtr podle IP (pro některé weby tohle může být lepší než klasický model uživatelů). V takovém případě skutečně v session stačí jen přihlášen=ano. |
||
| sifik Profil |
#16 · Zasláno: 14. 8. 2011, 21:06:59
Joker:
Tvůj způsob řešení krádeže session je zajímavý... V praxi si to ale nemůžeš moc ověřit, jak to funguje, ne? Jedině přes nějakou proxy bránu? Nebo jak zjistíš že takhle napsaná aplikace funguje korektně? Díky za vysvětlení. Chtěl bych se ještě zeptat, jak jsou na serveru ukládány proměnné session? Když na nějaké stránce je uložím, můžu k nim poté přistupovat odkudkoliv na serveru? Nebo je to omezeno např. složkovou strukturou? |
||
| Joker Profil |
#17 · Zasláno: 14. 8. 2011, 21:41:45 · Upravil/a: Joker
sifik:
„Tvůj způsob řešení krádeže session je zajímavý“ Teď nerozumím, o čem přesně je řeč? Nebylo to síš na o_O? Pokud je řeč o té kontrole IP adresy, tak uložení IP do session a automatické odhlášení v případě že se změní je celkem běžný postup. „jak zjistíš že takhle napsaná aplikace funguje korektně?“ Prostě se na testovacím serveru přihlásím, změním IP adresu uloženou v session a zkusím jestli mě to odhlásí. „Chtěl bych se ještě zeptat, jak jsou na serveru ukládány proměnné session?“ Do souboru. „Když na nějaké stránce je uložím, můžu k nim poté přistupovat odkudkoliv na serveru?“ Ano, pokud uživatel pod kterým běží daná aplikace má oprávnění ke čtení daných souborů. |
||
| sifik Profil |
#18 · Zasláno: 15. 8. 2011, 03:33:18
Joker:
Ano, to bylo na o_O. Překoukl jsem se. Aha, tak v tom případě se ještě musím zeptat, jak změním ip zvenčí, neboli za běhu aplikace? Ano, vím, že do souboru, akorát je mi divné, že když session uložím např ve složce a souboru root/admin/login.php, jak to, že ve složce root v souboru index.php moje session prostě neexistují? Nevíte, v čem by mohl být problém? Nebo proč se aplikace tak chová? |
||
| Joker Profil |
#19 · Zasláno: 15. 8. 2011, 07:36:46
sifik:
„jak změním ip zvenčí, neboli za běhu aplikace?“ Proč zvenčí? Přidám si do skriptu $_SESSION["ip"] /*nebo kam to ukládám*/ = "0.0.0.0";
„v souboru index.php moje session prostě neexistují“ Je v něm session_start? |
||
| sifik Profil |
#20 · Zasláno: 15. 8. 2011, 07:41:49
Joker:
Pravda, jdu na to zbytečně složitě, díky. Session_start mám nastaveno globálně na "on" v htaccess. |
||
|
Časová prodleva: 13 let
|
|||
0