Roze Posted July 26, 2008 Report Share Posted July 26, 2008 Manuprāt labāk ir izmantot DB priekš sesiju glabāšanas. Tas arī daudz efektīvākā veidā vienkāršo klāsterēšanu. Pričom te sesijas .. topics ir pavisam par citu lietotāju autorizācijas/datu mehānismu.. Kas attiecas uz sesijām ir arī efektīvāki veidi kā tās glabāt nekā DB.. Quote Link to comment Share on other sites More sharing options...
4e4en Posted July 27, 2008 Report Share Posted July 27, 2008 Nu ok, varbūt sesiju datus glabāt iekš DB nav pats efektīvākais variants, bet tas tik un tā ir efektīvāk, nekā visu gruzīt caur cepumiņiem... Quote Link to comment Share on other sites More sharing options...
v3rb0 Posted July 27, 2008 Report Share Posted July 27, 2008 ka es nekad nevarēšu izpildīt if(user_change_pw(..)) kā pēdējo rindiņu return mysqli_stmt_affected_rows($vaicajums)==1; un visu pārējo statusu vietā exceptionus mestu, jo no kļūdas, ka pazudusi db vai tabula,vai kverijs ar sql sintakses kļūdu, recoverēties biznesa loģikas līmenī īsti nevarēsi un nemaz ij nevajag. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted July 28, 2008 Author Report Share Posted July 28, 2008 4e4en, šī pasākuma mērķis īsti nebija uztaisīt metodi, kas 100% gadījumu 100% lietojumiem ir labāka, bet gan nodemonstrēt, manuprāt, ļoti interesantu pieeju autentificēšanai un arī sesijas datu glabāšanai (kaut gan pamatā gribēju nodemonstrēt tieši autentificēšanās mehānisma darbību, nevis uzsvērt sesijas datu glabāšanu šādā veidā). No autentificēšanās viedokļa labumi ir sekojoši: 1) Katru reizi tiek pārbaudīta parole un nevis tikai abstrakts if($_SESSION['authenticated'] == true) 2) Paroles datubāzē tiek glabātas spēcīgi aizsargātā veidā 3) Resursietilpīgā atslēgas ģenerēšana (atkarībā no gaumes to ciparu 512 var palielināt uz lielāku) notiek tikai 1x autentificēšanas sesijas laikā - tālāk tiek izmantots autentifikators, kura pareizības pārbaudei tiek pielietota tikkai viena hashoshanas iterācija. 4) No autentifikatora, pat ja izdodas atšifrēt servera ziņojumu, arī nav ieguvuma, jo sāls ir izvēlēts ar garumu, kas ir samērojams ar šifrēšanas atslēgas garumu (tātad, to nezinot, nav vispār praktiskas jēgas mēģināt kaut ko mēģināt uzlauzt) un izmantoto iterāciju skaits nodrošina to, ka pat dabūjot no DB paroles gala hashu un sāli, tomēr ir būtiski apgrūtināta pārlase pat zinot (vai izdarot minējumu), ka konkrētā parole ir vāja un atrodama kādā no vārdnīcām. Manuprāt, gan šai metodei, gan arī sesijām (klasiskajā PHP izpratnē) ir savas priekšrocības un, protams, arī savi trūkumi. Ja šo metodi izmantošu praksē, tad visdrīzāk kombinējot to ar jau pierasto PHP sesiju mehānismu. Quote Link to comment Share on other sites More sharing options...
anonīms Posted February 8, 2009 Report Share Posted February 8, 2009 (edited) Kādēļ man neatpazīst funkcijas, kuras sākas ar mysqli? Edited February 8, 2009 by anonīms Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted February 9, 2009 Author Report Share Posted February 9, 2009 Neatpazīst vai nu tādēļ, ka nav šīs bibliotēkas uzinstalētas/nokompilētas, vai arī php.ini failā nav norādīts, kur tās atrodamas. http://lv.php.net/manual/en/mysqli.installation.php Quote Link to comment Share on other sites More sharing options...
anonīms Posted February 9, 2009 Report Share Posted February 9, 2009 A ir iespējams šīs f-jas aizstāt ar mysql (nevis mysqli)? Vai arī tās ir divas dažās lietas? Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted February 9, 2009 Author Report Share Posted February 9, 2009 Ir iespējams. :) Uz šo metodi balstīta (bet neizmantojot nkārtīgo hashošanu!!!) realizācija: http://php.lv/f/topic/14660-login-script-with-cookies/ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.