Aleksejs

Pie reizes uzreiz arī vari pārbaudīt, vai username nepārsniedz pieļaujamo garumu. Ja ir zināms, ka 488762 simbolu garš lietotājvārdam nav vietas datu bāzē, tad labāk uzreiz atmest šādus lietotājvārdus nevis riskēt (kaut arī pietiekami minimāli) uzrauties uz kādas no DB komponenšu kļūdām attiecībā uz pārgariem datiem.

Skatoties - ko saprot ar matemātiku... Vidusskolas kursu nokārtoju savulaik uz "izcili", taču Fizmatos tik izcili vis vairs negāja ar to matemātiku viņas dažādajās izpausmēs :D

Nu, kā - uzliekam POP serveri uz localhost - un no PHP slēdzamies klāt ar: imap_open() (ļauj slēgties kā pie imap, tā pie pop serveriem), ja izdodas, tātad lietotājvārds/parole pareizi, jā nē, tātad nē. Labums: pop serveri jau ir varen sen un tajos jau ir pietiekami labi atstrādātas visas lomu dalīšanas un "grābstīsanās gar passwd/shadow failiem". Līdz ar to PHP (un http serverim) nav jāpiešķir nekādas papildus tiesības. Sliktums: Jāliek/jādarbina/jāuztur [iespējams] nekam citam nevajadzīgs serviss.

Es pēdējo reizi šim mērķim izmantoju POP serveri - autentificējas POP serverī, kurš tad attiecīgi autentifikācijai izmanto passwd.

ierakstu dalīšana pa lappusēm * http://php.lv/f/inde...?showtopic=2062 * http://php.lv/f/inde...p?showtopic=765 * http://php.lv/f/inde...?showtopic=1330 * http://php.lv/f/inde...?showtopic=2881 * http://php.lv/f/inde...?showtopic=2788 Meklēt te: http://php.lv/f/topic/2935-neliels-foruma-temu-apkopojums-no-arhiva-sadalas/

vari mēģināt palielināt pieejamo atmiņu: http://lv.php.net/manual/en/ini.core.php#ini.memory-limit

Tavs cmsss ir domāts vecākai PHP versijai - jaunākās versijās šāda funkcija nav. http://lv.php.net/manual/en/function.set-magic-quotes-runtime.php

Kādu vēl servera monitoru?! šitādu? http://php.lv/f/topic/8788-cs-16-monitors/page__view__findpost__p__72075

Linki izmainīti (tagad tie norāda uz nezinu kādu refereri).

Palīdzēt pastrīdēties? Pasaki, ka draugs ir neglīts un ka viņam kāja garāka par roku.

Visa pamatā vienalga ir un paliek parastā mirstīgā lietotāja ievadītā parole. Lielākai sāpei būtu jābūt no sāls nezināšanas (kaut arī, protams, sāls nav uzskatāma par vienādi slepenu informāciju kā parole). Zināšanai par to, kā tiek sāls pievienota parolei un kādā secībā notiek transformācijas, kā jau teicu nav būtiski jāietekmē uzbrukuma sarežģītību. + sensitīvo informāciju var sadalīt vairākās daļās - daļu padod webserveris kā HTTP headeri, daļa tiek dabūta no PHP skripta, daļa atrodas DB storētajā procedūrā, daļa DB tabulas laukā, piemēram.

1) 2) atrodi wikipediā 5) http://www.noupe.com/ajax/10-ajax-webmail-clients.html

@ezis: Ļaundaris jau nezina paroli. Kriptosistēmu veidošanā ir svarīgas tā sauktās Kērkhofa prasības, no kurām šajā kontekstā ir svarīgākā šī: 2) "Compromise of the system details should not inconvenience the correspondents." - jeb "Sistēmas uzbūves detaļu uzzināšanai nav jāietekmē sakaru drošība" Izvēloties aizsardzības metodi parolēm datu bāzē jārēķinās ar pesimistisko prognozi, ka tādā vai citādā veidā uzbrucējs varētu dabūt savā rīcībā datu bāzes kopiju. Līdz ar to uzdevums ir: 1) Apgrūtināt katras atsevišķās paroles uzminēšanu (glabāt paroles transformetā veidā - parasti transformācija irkriptogrāfiski droša jaucējfunkcija) 2) Apgrūtināt vienādo paroļu atrašanu (dažādiem lietotājiem izvēlēties dažādu transformāciju - parasti to dara pievienojot klāt sāli) 3) Apgrūtināt iegūtās informācijas izmantošanu citur (lietotājiem raksturīgi izmantot vienu un to pašu paroli daudzviet) 4) Zinot, ka lietotājiem raksturīgi izvēlēties vājas paroles, lai apgrūtinātu vārdnīcas uzbrukumu, padarīt paroles variantu pārlasi resursietilpīgāku (šajā vietā sāk runāt par key stretching utt..)

@ezis - viss ir atkarīgs no tā, ko tu saproti ar "savu algoritmu, kas pārveido paroles". Ja esi uztaisījis pats savu hash funkciju, tad tas 99,999999% gadījumu nozīmē, ka Tevis izveidotā funkcija būs varen nedroša [1]. Ja ar to saproti kaut ko līdzīgu md5(sha1($salt . $password). $password . $salt)... Tad vari tā darīt, kaut gan cilvēki, kas ar šīm lietām nodarbojas pastāvīgi [2], ir arī par to daudz domājuši [3]. [1] Why cryptography is harder than it looks. /Bruce Schneier/ [2] Hardened stateless session cookies. /Steven J. Murdoch/ (neapskatot ideju par visu autentifikācijas datu turēšanu pie lietotāja, tiek aprakstīts arī kā nodrošināt parolu aizsardzību) [3] Key strenghtening

Parādi ko atgriež: EXPLAIN SELECT story.id AS story_id, COUNT(votes.id_p) AS skaits FROM story LEFT JOIN votes ON story.id = votes.id_p GROUP BY story.id un SHOW CREATE TABLE story SHOW CREATE TABLE votes Nav indeksa uz id_p iespējams...

Vai šitāds nedod vēlamo rezultātu? SELECT story.id AS story_id, COUNT(votes.id_p) AS skaits FROM story LEFT JOIN votes ON story.id = votes.id_p GROUP BY story.id

Iespējams, PHP ir bez zip atbalsta Tavā gadījumā. paskaties, ko rāda phpinfo(); un paskaties, kā ieslēgt zip atbalstu: http://lv.php.net/manual/en/zip.installation.php

Ja ir izvēle, tad jāizvēlas sha1, jo md5 jau ir pietiekami salauzts.

Protams, ka nevar! Tu taču nezini, ka manam datoram nosēdusies CMOS batareja un katra diena iesākas kā 1994 gada 6. jūnijs... :P

Nu... es jau vispār neko neteicu - parādīju tikai to vietu, kur atrodama informācija. Pašam nav bijis IPB, tādēļ nezinu tā administrēšanas nianses, taču IPB oficiālajā dokumentācijā tam tā kā būtu jābūt izskaidrotam.

http://community.invisionpower.com/resources/official.html?category=40

Lietotāja līmenis tiek glabāts DB. Kad lietotājs tiek autentificēts, tad līmeni var glabāt kā sesijas mainīgo. Ja ļoti negribas izmantot sesijas, tad var katru reizi raustīt DB (atkarībā no tā, kāda datu bāze tiek izmantota, nav nepieņemams variants), vai arī glabāt pie lietotāja, bet tad šie dati paši par sevi ir kaut kādā veidā jāautentificē jāaizsargā pret patvalīgu izmaiņu veikšanu.

Nu, bet varbūt, ka viņš grib noskaidrot servera un datora pulksteņu rādījumu starpību :)

Nesen devu norādi uz šo projektu: http://phpgacl.sourceforge.net/ Varbūt ir vērts palasīt tā dokumentāciju: http://phpgacl.sourceforge.net/manual.pdf Tur ļoti skaisti viss (par piekļuves tiesību organizēšanu) aprakstīts :) Pirmajā norādē, ko devu iepriekšējā atbildē, manuprāt, arī gana sīki ar vismaz diviem piemēriem bija izskaidrota viena piekļuves tiesību piešķiršanas/kontroles metode. To, kā piereģistrēt lietotāju jau ±esi uzrakstījis.

par domēnu vhl.lv vien jau var relatīvi labu naudu dabūt...