Jump to content
php.lv forumi

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


millers

Recommended Posts

  • Replies 44
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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ā.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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 by Mr.Key
Link to comment
Share on other sites

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 by Mr.Key
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


×
×
  • Create New...