user levels ..... ar if ...

[andrisp]

Bet nu kaut ko tādu sākt te rakstīt... tikai vairāk jautājumus pretī dabūšu.

Nu nu..

[Aleksejs]

Bet nu kaut ko tādu sākt te rakstīt... tikai vairāk jautājumus pretī dabūšu.

Skumji...

[Toms]

Bet nu kaut ko tādu sākt te rakstīt... tikai vairāk jautājumus pretī dabūšu.

Hm.

[bubu]

e? Jūs smejaties vai kā?

50% useru šeit sagādā problēmas atrast savā kodā sintakses kļūdu vai ierakstīt/nolasīt datus no faila vai kaut kas tml... Kur tad nu vēl lietot tik "advancētas" funkcijas kā array_key_exists par kuru pat andrim p rodas jautājums "kāpēc" :)

 

(šis posts nav jāuztver ar 100% nopietnību)

[millers]

Nu tad ko man isti dariit =D

[millers]

aa un ka lai tad es padodu caur to tips kko lai nebutu ta notice ?

[Aleksejs]

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. ;)

[Mr.Key]

notice ir notice, tā tak nav kļūda un arī ne warnings.

 

principā visu var pārbaudīt arī kaut vai ar IFu, gan skaitli, gan stringu, gan array un ko vēl ne.

 

if ($mainigais) {

}

 

atkarīgsn no kodēšanas stila un koda pārskatāmības.

 

un kas liedz kodēt php brīvākā stilā un citas valodas ar rūpīgāku mainīgo apstrādi? array_key_exists() manuprāt ir izmantojams tiešām specifiskiem gadījumiem, kad ir svarīgi, ka tiešām tikai array_key_exists, bet tā pamatā izmanto isset ... var jau protams pie katra mainīgā taisīt 3 pārbaudes (isset, tad vai ir tips pareizais un tad vai ir vērtība), bet tas man liekas pa traku kaut kā.

[Aleksejs]

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

[Mr.Key]

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

 

okei, kas ir domāts ar drošību? nerunājot par sql injekcijām un auto global variables? kas notiksies, ja es iztikšu bez type castinga vai variabļa esamības pārbaudes, piem., salīdzinot if ($mainigais == 4) ?

[Aleksejs]

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

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

[Mr.Key]

Aleksejs, pilnībā piekrītu tavam citātam un tāpēc par kaut kādu drošību varam sākt runāt tad, kad ir skaidrs, kas ir notice, nevis tad, kad visi notice ir slikti.

 

Piemēram, skaidrs, ka šajā gadījumā vispār nav vērts runāt par drošību, ja usera levelis tiek noteikts pēc GET parametra. Tāpat arī neko nedos perfekta mainīgā apstrāde, ja, piemēram, datu integritāte daļēji balstās uz formas hidden laukiem.

 

Ir elementārs likums - uz production servera PHP Error messages ir OFF.

 

Tas, ka tiek likvidētas notices, neliecina par drošu kodu, pat tieši otrādi - nepieredzējušam koderim var likties, ka viss ir kārtībā, jo nav notices. Kā šajā gadījumā - lielais sasniegums - nolikvidēt notici pie GET parametra apstrādes lietotāja autorizācijas pārbaudei.

Edited August 1, 2008 by Mr.Key

[Mr.Key]

if (!$_GET['tips']) $_GET['tips'] = (int)$_GET['tips']; else $_GET['tips'] = (int)$_GET['tips']; :)

 

 

Nēea!!!!

 

$_GET vērtības ir paredzētas tam, lai nolasītu tās vērtības, kas ir URL GET parametros. Ir jābūt ļoti nopietnam iemeslam, lai $_GET vērtības sāktu modificēt... Sintaktiski tas ir pareizi, bet idejiski labs stils ir apmēram šāds:

 

$mans_tips = $_GET['tips'];

// ar variācijām, protams...

$mans_tips = false;
if (isset($_GET['tips'])) {
$mans_tips = $_GET['tips'];
}

// vai

$mans_tips = isset($_GET['tips']) ? (int) $_GET['tips'] : false;

// vai

$atlauti_tipi = array(1, 2, 3, 4);
$default_tips = 1;
if (isset($_GET['tips'])) {
if (in_array($_GET['tips'], $atlauti_tipi)) {
	$mans_tips = $_GET['tips'];
} else {
	die('Tavs IP nosūtīts policijai!');
}
} else {
$mans_tips = $default_tips;
}

utml.

 

GET un POST datu tips sākotnēji vienmēr būs String, jēga to pārveidot ir tad, ja aplikācijā tas ir nepieciešams.

Edited August 1, 2008 by Mr.Key

[Aleksejs]

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? :)

[Mr.Key]

Dažreiz 0 (nulle) var būt pilnīgi valīda vērtība, kas ar empty() paies garām..

 

Tādā gadījumā izmanto "if ($tips === 0) {...}"

 

Atkarīgs no koda lietojuma, noteikti nepaies garām situācija, kad jālieto empty() un kad tas vairs nederēs.