Cibiņš Posted February 28, 2011 Report Share Posted February 28, 2011 (edited) Diezgan interesanta lieta ar ko esmu saskāries - iekšējo sistēmu izveide, kuras datiem var piekļūt tikai autorizējoties bet nu, gribas zināt Jūsu, cienījamie kolēģi - vērtējumu par šo. Cik droši ir izveidot šādu sistēmu: Ir 3 faili index.php login.php template.php index.php failā: if (isset($_SESSION["id"]) && ($_SESSION["username"]) && ($_SESSION["time"])) { include('mape/template.php'); } else{ include('mape/login.php'); } login fails satur logina formu un logina parseri, kas izveido sesijas. Atrodas mape/login.php template.php <? if(isset($_SESSION["id"]) && ($_SESSION["username"]) && ($_SESSION["time"])) { ?> <html> <head> ...... </head> <body> tālākais kods... </body> </html> <? } else{ echo "Neesi ielogojies? Ej kakaat!"; } ?> Pēc logina pie attiecīgā logina datu rindas tiek updeitots TIME, kas tabulā glabājas vienādi ar logina laikā izveidoto time(); Gribas zināt cik droši ir šāda sistēma. Uzklausīšu Jūsu kritiku :) Edited February 28, 2011 by Cibiņš Quote Link to comment Share on other sites More sharing options...
m8t Posted February 28, 2011 Report Share Posted February 28, 2011 Par sistēmu pašu grūtu ispriest neredzot login.php failu, jo tur notiek visslielais "akšens". Tu tikai mums parādīji, kā tu čeko, vai lietotājs ir ielogojies vai nav. Lai mazāk būtu jāraksta kods vari vienkārši index failā darīt template.php faila include/require un iekš template faila veikt logi pārbaudi un ja lietotājs nav ielogojies = header('Location login.php'), jo pašlaik tu 2 reizes pārbaudi, vai lietotājs ir ielogojies vai nav. Vēl, ja ir vēlme, vari čekot vai sesija id un sesija time nevis pastāv (isset), bet gan vai tā ir int vērtība (pēc idejas kurai tai arī vajadzētu būt). Tad, protams, vari čekot vēl vai sesijā username vispār kaut kas ir ierakstīts iekšā ar empty(), bet tās ir tādas sīkas lietas, var būt arī tā kā tev ir. Kas ir jāatcerās? Logout.php failā izpildi funkciju unset(), nevis $_SESSION['lalala'] = '';, jo tavā gadījumā tu čeko vai sesija PASTĀV. Arī ja viņa ir tukša = viņa pastāv. Quote Link to comment Share on other sites More sharing options...
Kemito Posted February 28, 2011 Report Share Posted February 28, 2011 sessijā nebāz labāk saturu par lietotāja datiem, izvēlies unikālu idenfikātoru katram līdz ar to, pēc ielogošanās sesijā glabā ( kas attiecas uz lietotāja datiem ) pašu ID no kura atlasa datus. Quote Link to comment Share on other sites More sharing options...
codez Posted February 28, 2011 Report Share Posted February 28, 2011 Kemito, kāpēc sesijā labāk neglabāt lietotāja datus? Quote Link to comment Share on other sites More sharing options...
Kemito Posted February 28, 2011 Report Share Posted February 28, 2011 codez - uzglabājot unikālo identifikātoru TIKAI ( no lietotāju datu puses ) mēs sekojoši varam veikt ierakstu atlasīšanu, reāli arī tā labošanu. Uzgalbājot šos datus sessijā, izveidojot tādas lietas kā "Labot profilu" mēs labojot profila datus, uzreiz vēlamo rezultātu neiegūsim, bet gan tikai pēc atkārtotas autorizēšanās. Kā arī ir pieņemts lietot vismaz datubāžu struktūras pirmo normālformu, kurā pieņemts lietot identifikātoru ( id ), pēc kura atlasīt lietotāja datus. Vai kļūdos? Quote Link to comment Share on other sites More sharing options...
m8t Posted March 1, 2011 Report Share Posted March 1, 2011 @Kemito Pieņemsim ka tev ir 100,000 lapu web lapa. Tikai vienā no visām šīm lapām mums vajag izdrukāt kaut ko vairāk par lietotājvārdu. Kā būtu labāk - katrā no šīm 100,000 reizēm vienoties klāt datubāzei un vilkt laukā lietotājvārdu vai arī to saglabāt sesijā un drukāt laukā sesiju, bet tajā vienā izņēmuma lapā gan pievienoties datubāzei. Jāskatās ir no situācijas - ja ir tā, ka pārsvarā vajadzēs tikai dažus lietotāja datus, tad jau var glabāt tos sesijās, bet, ja lietotāja datus kā tādus vajag diezgan reti un katru reizi +- citus, tad jau arī varam glabāt tikai lietotāja id sesijā. Quote Link to comment Share on other sites More sharing options...
codez Posted March 1, 2011 Report Share Posted March 1, 2011 1) Kā jau minēja, lietotāja vārdu var nākties izvadīt daudzās lapās, piemēram headerī, "hello, john!" un lietotāja vārds parasti nemainās. 2) Sesijas datus var labot jebkurā brīdī, nevis tikai pie autorizēšanās. Protams lielā aplikācijā datu kešošana tiks realizēda modeļa vai db klasē un diez vai tam būs nepieciešams izmantot sessijas, taču vienkāršākās aplikācijās, ja šādas lietas netiek izmantotas, tīri labi datu kešošanu var veidot izmantojot PHP iebūvēto sesiju mehānismu. Quote Link to comment Share on other sites More sharing options...
Kemito Posted March 1, 2011 Report Share Posted March 1, 2011 @m8t - Ja jau lapas ir saistītas, tieši caur index`u tad kapēc atlasītos datus neuztaisīt globālus? @codez - Varu piekrist daļēji tev. Bet ir reizes, kad pastāv iespēja mainīt lietotājvārdu, epastu utml. Tos labojot, sessijas datus nāksies mainīt un tās ir papildus darbības reālā veidā, ja negribi atsevišķi bāst visu iekš sessijas atkal, manuprāt pieiktu ar identifikātoru, lieki nečakarējot sev prātu, laiku, un pirkstus. Vienalga palikšu pie tā, ka normālformas ir pareiza lieta, ko cilvēki izštukojuši, pie tā pieturēšos. Un pieturēšos pie tā, ka identifikātors katram, un to bāst sessijā IR LABĀK un PALIKS LABĀKS par to. āme sātan. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted March 1, 2011 Report Share Posted March 1, 2011 Nu ko lai saka... It depends... Quote Link to comment Share on other sites More sharing options...
m8t Posted March 1, 2011 Report Share Posted March 1, 2011 @Kemito Paraugu es biju domājis kā "ps.". Nebiju to domājis saistībā ar augstāk redzamo skriptu. Bet arī ja katras lapas headerī ir funkcija, kas velk laukā lietotāja datus no DB, tad 99,999 no maniem 100,000 gadījumiem tas būs vilkts lieki. Pie lieliem datu apjomiem tam būs nozīme, vai ir tiešām jāvelk laukā tas viss, vai arī var iztikt tikai ar to username iekš sesijas un miers. Viss ir atkarīgs no situācijas, kāda ir ar konkrēto lapu. Quote Link to comment Share on other sites More sharing options...
codez Posted March 1, 2011 Report Share Posted March 1, 2011 @codez - Varu piekrist daļēji tev. Bet ir reizes, kad pastāv iespēja mainīt lietotājvārdu, epastu utml. Tos labojot, sessijas datus nāksies mainīt un tās ir papildus darbības reālā veidā, ja negribi atsevišķi bāst visu iekš sessijas atkal, manuprāt pieiktu ar identifikātoru, lieki nečakarējot sev prātu, laiku, un pirkstus. Runa nav par prāta čakarēšanu, bet gan par aplikācijas ātrdarbībs palielināšanu. Bieži dati tādā pašā veidā tiek kešoti memcached un arī tur ir vajadzīgs pie datu izmaiņas mainīt gan memcache, gan db datus, taču parasti šīs darbības automatizē un piekabina kā modeļa funkcionalitāti, tādā veidā nekas papildus nav jākodē. Gadījums ar sesijām ir identisks, arī šeit var izveidot abstrakcijas slāni, kas to dara automātiski, neatkarīgi no datu daudzumu un variācijām. Vienīgais, praksē pie aplikācijām, kurās ir vērts veikt šādu optimizāciju, parasti būvē custom sesiju apstrādes mehānismu un parasti to saslēdz kopā jau ar esošu memcached kešošanas mehānismu un visbiežāk pat pilnībā visus sesijas datus glabā memcached serverī, lai paralēli varētu strādāt vairāki webserveri. Un šijā gadījumā tas ir tikai abstrakcijas slāņa mehānisma jautājums, vai ielogotā user datiem piekļūst caur sesijas mehānismu, vai caur kaut kāda autorizēto ūzeru klasi, kuras kešoti dati tāpat kā sesijas datu galu galā glabājas memcached serverī. Quote Link to comment Share on other sites More sharing options...
rATRIJS Posted March 1, 2011 Report Share Posted March 1, 2011 Tas ka datus glabaa sesijaa nenoziimee ka tiks izjauktas tabulu normaalformas. + tas ka var labot datus nenoziimee ka buus problemaatiski izlabot datus arii sesijaa. Nav veerts pie katra pieprasiijuma prasiit datus no datubaazes ja tos var kaut kur pieglabaat. Normaalos gadiijumos tas buutu nokeshots kaut kaadaa atminjas masiivaa (memcache n stuff), bet kaa jau codez teica - vienkaarshos gadiijumos sesijas ir gana labs veids to dariit. Quote Link to comment Share on other sites More sharing options...
Blitz Posted March 1, 2011 Report Share Posted March 1, 2011 Nu pastāv sesijas ID nozagšanas risks, domā pats cik tev tas ir aktuāli. Quote Link to comment Share on other sites More sharing options...
codez Posted March 1, 2011 Report Share Posted March 1, 2011 Nu pastāv sesijas ID nozagšanas risks, domā pats cik tev tas ir aktuāli. 1)Pastāv, ja ssh lietotāja vārds ir admin un parole password. 2)Ja pastāv tāds risks, tad defaultā varēs arī uzģenerēt sesijas kūkiju un tādā gadījumā varēs pieslēgties kā attiecīgais lietotājs, neatkarīgi no tā vai sesijā tiek glabāti lietotāja dati vai nē. 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.