Trac3 !! Posted August 31, 2009 Report Share Posted August 31, 2009 Sveiki. Es vēlējos noskaidrot vai ir vērts glabāt sessijas datus datubāzē vai tomēr izmantot parastos teksta failus, kas pēc noklusējuma jau ir.? Mani interesē plusi, mīnusi un jūsu viedoklis :) Quote Link to comment Share on other sites More sharing options...
Kemito Posted August 31, 2009 Report Share Posted August 31, 2009 īsti nezinu neko par teksta failā glabāšanu, bet es izmantoju, ja izmantoju Datubāzē! Visnotaļ uzskatu ka tā ir ērtāk. Quote Link to comment Share on other sites More sharing options...
Web Developer Posted August 31, 2009 Report Share Posted August 31, 2009 Defaultā glabājas failos vai servera runtime memory. Bet var arī izmantot "user defined" un glabāt datubāzē. Iespējams, iegūsi nedaudz lielāku kontroli pār sesijām, nekā izmantojot defaultās metodes. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 31, 2009 Report Share Posted August 31, 2009 Lietas, kas uzreiz ienāca prātā. Plusi glabāšanai bāzē: * Neglabājas failu sistēmā - tādēļ lielākoties atkrīt visas drošības problēmas, kas saistītas ar sesijas datu nolasīšanu caur failu sistēmu (kas ir iespējama slikti nokonfigurēta servera gadījumā). * DB ir piemērotāka sadalītai sistēmai - līdz ar to sesijas ir vienkāršāk padarāmas pieejamas vairākos fiziskos web-serveros vienlaicīgi slodzes dalīšanai * DB ir potenciāli ātrāka datu apmaiņai (te gan ir jāizvērtē, jo savienojuma nodibināšana un pārtraukšana prasa laiku) Mīnusi glabāšanai bāzē: * Jārūpējas par datu validāciju, lai nepieļautu DB līmeņa drošības pārkāpumus (SQL injekcijas, piemēram) * Atkarībā no realizācijas sanāk, ka zinot DB lietotāju un paroli ir iespējams daudz vienkāršāk iegūt _visu_ sesiju datus. (SELECT * FROM sesijas). Vieglāk pat nekā pie glabāšanas failu sistēmā. Quote Link to comment Share on other sites More sharing options...
Web Developer Posted August 31, 2009 Report Share Posted August 31, 2009 * Par datu validāciju jārūpējas jebkurā gadījumā... * Ja iegūst db jūzeri un paroli, tad var ne tik to vien redzēt datubāzē... Jūtīgos sesijai nepieciešamos datus (piemēram, paroli - kaut gan to nevajag ilgāk glabāt) var pārvērst par hash un salīdzināt. Var datus datubāzē slēpt kaut kā aizkodējot... Protams, tas nekādu drošību negarantē, bet arī ne pārskatamību. Galu galā šīs ir datubāzes menedžmenta problēmas lielākoties. Pie plusiem: * Fakts, ka sesiju var vairāk kontrolēt un izveidot "advancētāku", ja glabā datubāzē... Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 31, 2009 Report Share Posted August 31, 2009 Lai samazinātu risku ir ieteicams sesiju datu manipulēšanai izveidot īpašu DB lietotāju, kuram būtu tikai tiesības izpildīt stingri noteiktas "stored" funkcijas un pilnīgi neko citu. Quote Link to comment Share on other sites More sharing options...
Web Developer Posted August 31, 2009 Report Share Posted August 31, 2009 Var aizrauties ar paranoju, bet ja datubāze ir svarīga, nevis kaut kāda "vakara ziņu" krātuve, tad arī ir jābūt cilvēkam, kas nodarbojas ar datubāzes menedžmentu... Principā tas nav profesionāla web programmētāja lauciņš (nevar būt eksperts php, eksperts javascript,css un eksperts vēl datubāzēs). Ja domā, ka "eksperts" visur, tad patiesībā - labākā gadījumā viduvējība visur. Tur tas cilvēks varētu arī uzturēt datubāzi un programmēt storētās procedūras. Protams, ja ir vēlme un azarts, lēnā garā var darīt to pats (saviem projektiem...) Quote Link to comment Share on other sites More sharing options...
bubu Posted August 31, 2009 Report Share Posted August 31, 2009 Web Developer: kāds tam visam, ko saki, ir sakars ar autora jautāto faili vs datubāze? Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 31, 2009 Report Share Posted August 31, 2009 Ja sistēma ir svarīga, tad tās izstrādē piedalās īpašs paranojas eksperts, nevis tikai DBA. Uzskatīt, ka produkcijas sistēmā tiek veidotas, mainītas un dzēstas funkcijas un procedūras (ka vispār tiek veiktas kādas nedokumentētas izmaiņas) bez iepriekšējas testēšanas vispirms izstrādes, tad testa un visbeidzot akcepta vidē ir ļoti nenopietni. Bet kā jau teica bubu - šī tēma ir par sesiju glabāšanas failos vai DB izvērtēšanu. Quote Link to comment Share on other sites More sharing options...
krikulis Posted September 1, 2009 Report Share Posted September 1, 2009 Pirmkāŗt, zināma prbl. šajā gadījumā ir linux distru pačotā source, piem ķeska ar Ubuntu: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/316441 Rezumējot: expairējušās sesijas netiek dzēstas. Sanāk diezgan daudz kopā junk datu db. Otrkārt, DB levelā privilēģijas bieži vien ir vieglāk enforcēt kā failsistēmas levelā. Treškārt, DB var klasterēt, skeilot labāk nekā failsistēmu. Ja aplikācija ir deployota uz vairākiem serveriem, sesiju šeirošana ar FS ir PITA ar visiem NASiem/SANiem utt. Ceturtkārt, ja vien nenotiek baisa nelaime, ja sesija pēkšņi pazūd, tad memcached ir labākais un ātrākais variants. (Skeilošana, HA utt). Piektkārt, PHP bai default sesijas glabā failos, dīvaini serializētā formā (php.net/session_encode), php.ini norādītā dirā, kur faila nosaukums sakrīt ar sesijas id. Daži freimworki, piem. Horde un CodeIgniter ir izgudrojuši riteni no jauna un ir savs sesiju mehānisms, nevis PHP iebūvētais. Principā augstāk rakstītais varētu atbilst arī jamo implementācijām, kaut gan neesmu jamās iedziļinājies un neredzu iemeslu, kādēļ jamās ir rakstītas. Quote Link to comment Share on other sites More sharing options...
Delfins Posted September 1, 2009 Report Share Posted September 1, 2009 tikai atceraties, ka sess-db ir vēl viens papildus SQL uz DB.. un ja dati nav serializēti, tad vēl vairāk datu pumpēšanas [serveri jāatvel resursi uz katru pieprasījumu un t.t.] Un nav jau nekādas problēmas šārot sessiju folderi tīklā... ja jau webs ir tik liels un klāsterēts, tad gan jau arī normāli sakonfigurēts. Pats par sevi saprotams. Es, piem., izvairītos no DB slogošanas. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted September 1, 2009 Report Share Posted September 1, 2009 Vēl viena labā īpašība ir sesijas datu vienkāršāka pieejamība citām sistēmām, kas iespējams programmētas pavisam citā valodā un pilda citus mērķus. Quote Link to comment Share on other sites More sharing options...
Delfins Posted September 1, 2009 Report Share Posted September 1, 2009 un kas tas būtu? reāls piemērs, lūdzu? Varbūt varētu būt kāda oline spēle?,.. bet anyway - vieglāk to uzreiz glabāt kādā normālā veidā iekš DB un t.t. Ja grib kaut ko kopā salāgot, jāuztaisa interfeiss.. kaut vai starptabula. nevis rakņāties pa sessijas datiem, kas ir php-only darīšana (pofig, ka tikai read-only), un nav svarīgi DB/faili... Sessija domāta lietotājam tekošie settingi uz servera. Man piem. nepatiktu, ka kāda programma ložņātu pa sessijas datiem. (Un)Serializācijas algoritmu nemaz nav tik grūti uzrakstīt. Galu galā ir labs teiciens - labāk neaiztikt to, kas strādā daudz maz normāli un stabili. Pārbaudītas vērtības, kā saka. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted September 1, 2009 Report Share Posted September 1, 2009 Reāls piemērs - lietotāja autentifikācijas pārbaude, lai tiktu klāt *.iso failam, kur autentificējamies caur PHP aplikāciju, bet iso failu mums servē pa taisno apache, kas pārbauda vai lietotājam ir tiesības piekļūt failam ar Apache moduli. Protams, katra jauna konstrukcija sarežģī dzīvi, taču ja jāsaintegrē kopā vairākas dažādu ražotāju aplikācijas, tad šis ir viens no veidiem kā to izdarīt. Quote Link to comment Share on other sites More sharing options...
rpr Posted September 1, 2009 Report Share Posted September 1, 2009 ko juus ar to serializaaciju domaajat? ko tas noziimee? Aleksej, a tu izmanto gatavu apache moduli? mees te arii vienu taadu uzcepaam, jo atrast gatavu taa arii nesanaaca. 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.