Aleksejs

if(!isset($_GET['page'])) { $page = 1; } else { $page = mysql_real_escape_string($_GET['page']); } $max_news = 4; aizvieto ar if(!isset($_GET['page'])) { $page = 1; } else { $page = mysql_real_escape_string(intval($_GET['page']));//intval()!!! } $max_news = 4;

Ja tas nav saistīts ar satura aizsardzību pret izmantošanu citur, tad, jā var ar CSS. http://www.webdesignerwall.com/tutorials/c...rative-gallery/

Šī ir viena no tām lietām, kas, interesantā kārtā, (cik man zināms) nav atrisināma ar JavaScript (vismaz tādā līmenī, kurā man liktos, ka lieta ir atrisināta), bet gan ar kaut ko līdzīgu GD vai imagemagick...

Mr. Key, Tieši tā - Kā dzied Alphawille - "Hoping for the best, but expectng the worst" ;) Tieši šī ideja - Izstrādājiet ar ieslēgtiem visiem iespējamajiem brīdinājumiem, bet ieviesiet produkcijā ar minimāli iespējamajiem klienta pusē (tas ir uzraudzītāja pienākums) brīdinājumiem. Šajā, es pilnīgi piekrītu. ;) Tieši šī pati diskusija daļēji attiecas uz @ lietošanas pirms funkcijām - izstrādē nekādā gadījumā, bet produkcijā neiesakām. Ir atšķirība, vai ne? :)

Nē, nu, ja vari visu, visu uzrakstīt saskaņā ar to, tad ir ļoti jauki. Par wap - labi bija laacz.lv aprakstījis Es lietoju lielākoties xhtml transitional. Man ir tikai tā priekšrocība, ka lielākoties manā pārziņā nav attēlojums pārlūkā. :)

Notice pats par sevi atklāj (atkarībā no "setupa") iekšējo skripa struktūru, kura pēc pieņēmuma par "server-side" skriptu būtību, paredz, ka skripta saturs tiek noslēpts no apmeklētāju acīm. Pat tikai fakts, ka skripts "paziņo", ka ir radies kāds neapstrādāts izņēmuma gadījums jau atkarībā no pieņēmumiem un uzstādnēm par sistēmas drošību nozīmē, ka zināmā mērā sagaidāmais drošības līmenis (sensitīvas informācijas izplatīšana) ir pazeminājies. Un kā rāda prakse - izņēmuma gadījumu paredzēšana noved pie krietni drošāka galarezultāta, nekā pieņēmums "šo nevajag pārbaudīt, jo tas nav tik svarīgs", kurš gala rezultātā labākajā gadījumā beidzas ar "Uppps!" Ļoti labi par šo lietu nesenās DNS ievainojamības sakarā stāstīja Brūss Šneiers: http://www.schneier.com/blog/archives/2008...ns_vulnera.html

Mr. Key, jā... optiimizācija ir laba lieta, taču tā nedrīkstētu stāvēt pāri drošībai ;)

bubu, nu kaut kā tā izklausījās ne tā ;) Zini kā... piektdiena... visi ar nepacietību gaida brīvdienas... stress... putuplasta ruksis ir, bet dienvidu tilta nav... :D Miller, nu es teiktu, ka ja padosi: www.millerasupersaits.lv/superlapa.php?tips=2 , tad nebūs notice nevienā no gadījumiem. Bet tā - ņem bubu variantu. ;)

Skumji...

Jā, tik tiešām! Redz, cik es tālredzīgs, ka nederēju :D P.S. Pārbaudīts arī eksperimentāli.

Lai nebūtu notice ir jāizmanto- isset(); tobiš: $msg=''; //Better safe than sorry - tāpēc nodefinēsim mainīgo tukšu if(isset($_GET['tips'])){ switch($_GET['tips']){ case 1: $msg='Tu pirmā tipa lietotājs'; break; case 2: $msg='Tu esi otrais tips'; break; case 3: $msg='Tu esi trešais... tēva dēls'; break; case 4: $msg='Tu esi ceturtais tips...'; break; default: $msg='Tu esi, kaut kas netipisks. Man bail!'; } } else { $msg = 'Tu esi pilnīgi netipisks! Gribi par to parunāt?'; } echo $msg; EDIT: Andri, negribu derēt, bet man šķiet, ka empty arī ģenerēs Notice :)

Notice it tad un tikai tad, ja neesi padevis caur adresi tips=blabla default: varēja neaiztikt - ne tur tā vaina :)

http://www.opera.com/wsc/ Learn to build a better Web with Opera Learning Web Standards just got easier. Opera's new Web Standards Curriculum, released in association with the Yahoo! Developer Network, is a complete course to teach you standards-based web development, including HTML, CSS, design principles and background theory, and JavaScript basics. It already has support from many organizations (including Yahoo! and the Web Standards Project) and universities. The first 23 articles are currently available, with about 30 more to be published between now and late September. P.S. Man ir tieši tāda Pilot pildspalva, kā attēlā :)

Pirmkārt: nevis $_GET['tips']=4 bet gan $_GET['tips']==4 ;) Taisi ar switch: switch($_GET['tips']){ case 1: $msg='Tu pirmā tipa lietotājs'; break; case 2: $msg='Tu esi otrais tips'; break; case 3: $msg='Tu esi trešais... tēva dēls'; break; case 4: $msg='Tu esi ceturtais tips...'; break; default: $msg='Tu esi, kaut kas netipisks. Man bail!'; } echo $msg;

Esmu saskāries un saskaros ikdienā darba sakarā ar šīm lietām. Jāģenerē jau Tev tā vai tā uz sava datora būs ;) Vienkārši to uzģenerēto publisko daļu tad arī tas trusted sertifikators arī paraksta. Faktiski ir tā. Minimālais, ko vari izdarīt: uzģenerēt "self-signed" sertifikātu. Protams pārlūks lamāsies, bet iespējams, ka tā nav problēma un konkrētajā gadījumā un lietotāji var pirmo reizi pieslēdzoties ieķeksēt, lai šo sertifikātu uzskata par trusted. Nākošais: Izmantot cacert.org pakalpojumus. Zinu, ka daudzi privātiem mērķiem to izmanto. Mīnuss - pārlūkos nav cacert.org root sertifikāts trustētajos sertifikātos (līdz ar to situācija ir varen līdziga kā pirmajā gadījumā ar atšķirību, ka lietotāji var izvēlēties vai ticēt tikai tavam sertifikātam, vai arī uzreiz ieimportēt cacert.org un tad viņiem visi cacert.org parakstītie rādīsies kā trusted) Tad nāk iespēja parakstīt kādā no pārlūkos izplatītajiem Root CA: ls /etc/ssl/certs ;) Taču, ja gribēsi izmantot ibankas pakalpojumus nāksies sašaurināt pieejamo sertifikatoru klāstu un izmantot kādu no lielajiem: Verisign, Thawte, GoDaddy, Valicert utt. (patiesībā var prātā sajukt, kamēr saprot kurš kuru kad un kāpēc ir parakstījis). +ja gribēsi lai būtu EV SSL sertifikāts - nu tāds, kas rāda zaļo joslu jaunajā FireFoxā (un jaunajā IE), tad nāksies škirties no ~2x lielākām naudiņām. [edit]P.S. Gribēju tikai piebilst, ka ar ibanku domāju visādus B2B pasākumus, kur tiek no/uz banku/sms_centru utt sūtīti kaut kādi ziņojumi

$datums_kad=mktime(0,0,0,8,9,2008); $tagad = mktime(); $cik = $datums_kad - $tagad; $cik_dienas = 'Atlikušas '. intval($cik/(60*60*24)) . ' dienas';

http://www.webappers.com/category/components/gallery/ Ej cauri un skaties.

http://sandbox.leigeber.com/slideshow/

Apsveicu Delfīnu dzim;sanas dienā! Lai vienmēr 3 pēdas ūdens zem astes spuras :D

Show must go on... Šis jau izskatās pēc Distributed Slavebased Debugger...

Piekrītu, jo šie statusi faktiski apzīmē to, cik aktīvi cilvēks piedalās diskusijās un cik sen šis cilvēks ir forumā, nevis zināšanu līmeni. Man īpaši šie statusi netraucē (O! Starp citu kopš iepriekšējās nedēļas arī es sparīgi spamojot esmu dabūjis augstāko kategoriju :D), taču varu iedomāties, ka kāds dažādu iemeslu dēļ varētu nebūt tik iecietīgs...

Tādā veidā sesijas mainīgos neuzstāda. Izmantojot formu, Tu uzstādi $_POST['name'] - tālāk skriptā Tev atkarībā, no tā vai ir vai nav pareizi, šī vērtība ir jāpiešķir $_SESSION['name'] mainīgajam, kurš tad nu pēc šīs uzstādīšanas būs pieejams.

Emmm... atveram lv.php.net un ierakstam meklētājā md5 Ieraugam, ka tieši tā arī iekš PHP iebūvētā funkcija saucās. Bet jaunam projektam neieteiktu izmantot md5, ja vien nav kādu īpašu ļoti, ļoti, ļoti svarīgu iemeslu, kādēļ to darīt.

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.

Sveiks! Ceru, ka pirmajā punktā pārteicies un, ka gribi aizsargāties pret DDoS uzbrukumiem, nevis aizsargāt pašus DDoS uzbrukumus ;) Lasāmviela pārdomām: http://www.nag.ru/2003/0323/0323-text.html http://www.nag.ru/goodies/netbook/ch9.html#7 http://www.membrana.ru/articles/internet/2.../21/192300.html http://www.securityfocus.com/infocus/1655 Faktiski - labākais, ko sava gadījumā vari izdarīt - izveidot savu web aplikāciju tik noturīgu, lai par šaurāko vietu kļūtu tīkla pieslēgums. Kā ar jebkurām citām drošības lietām izvērtē, kādus pasākumus veiksi katrā no šīm jomām: Protection - kādus aizsardzības līdzekļus izmatosi Detection - kādus uzraudzības līdzekļus izmantosi un kā noteiksi, ka ir problēma Action - kā reaģēsi, ja ir problēma kā tavas darbības izmainīs pirmos divus punktus...