Aleksejs

Vai līdz PHP kaut kādi dati aiziet? Vai arī tas jau iekš AJAX apraujas?

Nu jā, par koda estētiskumu galīgi nestrīdos - šis jau tikai tāds koncepts, lai paskatītos, kā/vai vispār darbojas. Par statusu returnošanu arī taisnība, pašlaik ir ideja pārtaisīt, ka funkcijas atgriež true/false un attiecīgās vērtības, lai piešķir padotajiem parametriem + vēl kā parametru padot $error_log masīvu, kuram tad kabināt visuas excepcijas, lai beigās varētu korekti sažurnalēt/atgriezt kļūdas paziņojumu. Pie mysql storēto funkciju/procedūru izmantošanas tieši šobrīd darbojos. :) Par kompresiju arī - vakar sāku pētīt, ko var darīt lietas labā, principā jau nekas īpaši vairāk nav - 1 rindiņa gzcompress($data) un viss... Vienkārši atkal sakarā ar to, ka tas bija tikai koncepts, neko īpaši vairāk neveidoju. Kādu kompresijas metodi ieteiktu? Par IP adreses izmantošanu/neizmantošanu arī esmu daudz domājis... Faktiski ar atgriesto statusu jau redz, vai ir mainījusies tikai adrese 6 vai arī nekas nav mainījies 7... Līdz ar to, pēc vajadzības var IP adreses pārbaudi neņemt vērā.

Mikij, vai Tev sagādā baudu parādīt tabulu ar vieniem lauku nosaukumiem un tad SQLu ar citiem lauku nosaukumiem? Vajag ORDER BY datums, laiks

Āāāāā :D

Bubu, jā, ar "turēt uz servera" biju domājis tieši iebūvētās PHP sesijas gadījumu.

Jā, tā tas notiek. Ja ir lieli (cik lieli ir lieli ;) ) sesijas dati, tad jādomā, ko darīt, vai sūtīt katrā pieprasījumā, vai turēt uz servera, vai arī kombinēt abas metodes.

Un ko viņš ieraksta log failos, kad nevar piestartēt?

Пал смертью храбрых :D Krita varoņa nāvē ;) (tiem kas nesaprot krievu val.)

Man ir šāda versija: Kad notiek izlogošanās sesijas handleris izdzēš sesijas cookiju. pēc tam (kā tam pareizi arī būtu jābūt) tiek reģenerēts sesijas ID, taču to vairs handleris nevar uzstādīt cookijā (jo dati jau aizsūtīti) tādēļ tas izmanto nākošo pieejamo metodi un uzstāda ar GET. Kā jums šķiet, vai tā varētu būt?

Jap - tad skaties Andra doto linku ;)

Nē, nav vienīgais. Vēl daži argumenti no manis daudzinātā "Hardened stateless session cookies"[1][2]: Būtībā, nav problēma arī šo sistēmu papildināt ar sesijām raksturīgajām lietām - šīs pašas funkcijas sakombinējot ar: http://lv.php.net/manual/en/function.sessi...ave-handler.php iegūstam apvienojumu no abiem - iespēju darboties ar $_SESSION mainīgajiem un šīs shēmas plusus. Pie kam, ja pareizi izveidojam, tad iegūstam, ka jaunu sesiju (PHP izpratnē) izveidot var tikai autentificēts lietotājs, kas neļauj notikt ar pirmo pieminēto citātu saistītajām resursu pārpildīšanās problēmām.

Parādi .htaccess faila saturu Un pameklē, kur Tev atrodas error_log, un paskaties, tur būtu jābūt paskaidrotam, kas tieši neiet.

šeit nedaudz virs 5 ;) Bet forumos kā tādos... ~10 ;)

Ak, jel! Un tieši šodien 1x pa gandrīz 10 gadiem man sagribējās uzlikt avataru :D

Hmm... Es laikam esmu nežēlīgi, nežēlīgi dumjš... Bet tā arī neatradu vietu, kur uzlikt avataru :S

Neko konkrētu ieteikt nemāku. Zinu dažus, kas lieto Joomla... Papēti to;)

Andri - jā ;) Pascal ietekme uz organismu.

Pirms dažām dienām solīju parādīt kā izskatās lietotāju autentifikācija, kas nebalstās uz sesijas mainīgo izmantošanas un kas izmanto "Hardened stateless cookies". Tad nu te ir tas, kas sanācis. Uzreiz brīdinu, ka pārāk briesmīgi ar komentēšanu neesmu aizrāvies, tādēļ ja ir jautājumi pēc būtības par tiem vai citiem izvēlētajiem risinājumiem, centīšos uz tiem pēc iespējas atbildēt. Vēl jāpiebilst, ka kaut arī sapņoju kādreiz nopietni pieķerties OOP, tomēr arī šoreiz kods ir rakstīts procedurāli, tādēļ OOP aizstāvji nesitiet mani. ;) Vispirms sākam ar datubāzes uzbūvi. Esmu pieņēmis, ka lietotāju dati glabājas datu bāzē users: sqls, kas izveido datubāzi un pievieno lietotāju "labietis", kuram uzstāda paroli "parole". (iekš paste.php.lv neielikās): Tālāk pārejam pie funkcijām: fails auth_common.php satur funkcijas un mainīgos, kas nepieciešami autentifikācijas pārbaudei; fails auth_logon.php satur funkcijas kas apstrādā nehashotas paroles, un kas dabū no lietotājvārda lietotāja ID; fails auth_user_management.php satur funkcijas, kas ļauj izveidot jaunus lietotājus, nomainīt paroli norādot/nenorādot veco paroli kādam no lietotāja ID, kā arī palīgfunkcijas. Tālāk seko piemēri šo funkciju izmantošanā: login lapa: logon.php; autentifikācijas pārbaudes lapa autentifikators.php, kuru paredzēts ar require_once() izsaukt katras aizsargājamās lapas sākumā - kā piemēram te: index.php; logoff lapa: logoff.php būtībā izdzēš autentificēšanas cookie; Administratora lapa user_mod.php lietotāju paroļu (arī savas!!! un tad būs jāielogojas ar jauno paroli, lai turpinātu darbu) nomaiņai. Administratora lapa jauna lietotāja pievienošanai user_add.php demonstrē funkcijas admin_create_user() izmantošanu. Lietotāja lapa savas paroles nomaiņai change_pass.php Cerams, ka kodā kļūdu nav un, nevajadzētu arī darboties SQL injekcijām. Šīs autentifikācijas metodes plusi: Uz servera nav jāglabā sesijas dati (tam ir paredzēts $user_data[5]), līdz ar to var vienkāršāk veidot klāsterus (jo savā starpā nav jāsinhronizē sesijas dati). Cookiju var izmantot tikai no tās pašas IP adreses. Paroles maiņa nākošās darbības veikšanas reizē liek pārlogoties pilnīgi visiem konkrētā lietotāja aktīvajiem pieslēgumiem. Dati cookijā glabājas lietotājam nepieejamā veidā un ir aizsargāti pret manipulāciju. Mīnusi: Nav nojausmas par to cik reizes konkrētais lietotājs ir pieslēdzies. Kas būtu vēl darāms: Jāizveido stored procedures/funkcijas, kurām vienīgajām ir piekļuve laukiem salt/password - visiem pārējiem web-aplikācijā izmantotajiem sql lietotājiem liegt pieeju šiem laukiem un tikai īpašiem autentifikācijas lietotājiem ļaut darbināt stored procedūras.

Gribēju tikai pateikt, ka darbs ir gandrīz pabeigts - tikko pabeidzu rakstīt. Tagad uzlikšu PHP & MySQL & Apache un sākšu testēt.

Sadarbība, nevis darbs tur ;)

Nē, nepaliek. Skaties te: http://lv.php.net/manual/en/function.fopen.php

@ zīme pirms PHP funkcijas nodrošina to, ka PHP neģenerē error/warning paziņojumu, ja funkcija izpildās nesekmīgi. P.S. Pēc semikola noņemšanas apache pārstartēji?

Cik redzu no TEvis ieliktā, tad pirms mainīgā sendmail_from iekš php.ini ir semikols, kas nozīmē, ka šis mainīgais ir aizkomentēts. Rekur vēl bija kaut kas par mailu konfigurēšanu: http://php.lv/f/index.php?showtopic=9018&hl=mail

Atkomentē to e-pasta adresi php.ini failā.

Atkarīgs no mail.livas.lv konfigurācijas, taču klientiem parasti ļauj "RELAYot" ar jebkādām adresēm.