kdyz kliknu na odkaz:
<a href=""http://www.modflex.com/buxus/web/cz/Products/Development-Tools/modFlex/Freehosting/">freehostingu</a> a i jine..
casto se mi zobrazi na poprve neuplny obsah (len leva cast) a az po reloadu take cast vpravo o freehostingu ? dela vam to take nebo je chyba na strane meho pocitace?
Rad bych se take zeptal v cem spociva nizka bezpecnost programovani v php ?
pr clanky mi nevadi jen mi vadi ze nejsou jako pr oznaceny - ze se jedna o pr soudim nejen podle zmince o soutezi..
za vysvetleni predem dekuji
Vlákno názorů k článku
Budeme mít "novou Adu a bezpečné PHP?"
Pepak (neregistrovaný)
13. 7. 2004 11:04
Re: -
Rad bych se take zeptal v cem spociva nizka bezpecnost programovani v php ?
IMHO v tom, ze PHP toleruje (pokud ne primo podporuje) neprilis bezpecne programatorske navyky a postupy (napriklad nedostatecnou kontrolu vstupnich dat). Jen mam pochybnosti, jestli to dokaze za programatora vyresit jazyk.
Lukáš Lánský (neregistrovaný)
13. 7. 2004 13:17
Re: -
V takovém ASP.NET se všechna data z formulářů procházejí a pokud obsahují "nebezpečné" konstrukce typu "<br>", systém vyhodí chybu s popisem, jak tyto data povolit. Podle mne je to zajímavé řešení, protože začátečníka trkne fakt, že by se měl o tyto věci starat a pokročilejší programátor si to automaticky vypne ve web.config...
dgx (neregistrovaný)
13. 7. 2004 15:15
Re: -
Je pravda, že PHP ve standardní konfiguraci svádělo nezkušené programátory k tvorbě velmi snadno nabouratelných aplikací. A také je pravda, že tvůrci PHP si to uvědomili a snaží se situaci změnit. Jenže konfigurace (a vůbec verze) PHP závisí většinou na správci hostingu, tudíž bude ještě nějakou dobu trvat, než se PHP zbaví tohoto dědictví z minula.
Ale nic to nemění na tom, že jakkoliv děravě nakonfigurované PHP není překážkou pro budování velmi solidních aplikací, pokud to programátor UMÍ. Záleží jen a jen na jeho schopnostech. A kde nejsou schopnosti, nepomůže ani modFlex ;-)
Ale nic to nemění na tom, že jakkoliv děravě nakonfigurované PHP není překážkou pro budování velmi solidních aplikací, pokud to programátor UMÍ. Záleží jen a jen na jeho schopnostech. A kde nejsou schopnosti, nepomůže ani modFlex ;-)
... (neregistrovaný)
13. 7. 2004 15:31
Re: -
no jasne, me slo o to, jestlize ja budu dodrzovat postupy ktere tvurci pozaduji tak jestli je php bezpecne nebo jestli postupy musim obchazet pro psani bezpecnych aplikaci, .. proste mi nesedela ta vina na strane php
(zvlaste takto nepredpokladam u lidi pisici aplikace internet bankingu..)
OT: nejaky solidni komplexni zahranicni(EN) zdroj pro vyuku byste prosim nedoporucily? diky
(zvlaste takto nepredpokladam u lidi pisici aplikace internet bankingu..)
OT: nejaky solidni komplexni zahranicni(EN) zdroj pro vyuku byste prosim nedoporucily? diky
dgx (neregistrovaný)
13. 7. 2004 15:37
Re: -
Ne, můžeš úplně klidně psát aplikace v PHP. Ale pomalu si projdi třeba tuto sérii článků a zjistíš, na které věci si dávat pozor. Tyto techniky se většinou netýkají jen PHP (nebo třeba MySQL), ale vlastně všech platforem nebo databází, včetně těch velmi velmi drahých.
Mormegil (neregistrovaný)
13. 7. 2004 15:42
Re: -
Jde o to, ze jsme jenom lidi, takze nikdo neni "dobry programator" v tom smyslu, ze by nedelal zadne chyby. A pokud se v nejakem PHP preklepnu a misto "if (neplatnadata) die(x)" napisu "if(nwplatnadata) die(x)" tak to ma potencialne velmi neprijemne nasledky. (mod)Flex mi brani udelat podobnou chybu, cimz zvysuje tu bezpecnost. Ale otazka idealni miry takovych kontrol je evidentne veci osobniho vkusu.
Solvina (neregistrovaný)
13. 7. 2004 15:59
Re: - (OT)
Promenou nemusite deklarovat. Na urovni nastaveneho hlaseni chyb zalezi, jestli Vas na to interpreter upozorni
- melo by se pouzivat pri vyvoji: error_reporting(E_ALL);
- zakaznikovi davat: error_reporting(0);
Vychozi nastaveni (asi E_NOTICE) je prasarna. Skoda, ze spousta PHPkaru bere zakladni nastaveni jako zaklad a nastaveni maximalni uroven povazuje za zbytecnou buzeraci.
Dalsi vtipne veci se v PHP daji provadet s register_globals=on, ale to je pomerne znama pohadka.
- melo by se pouzivat pri vyvoji: error_reporting(E_ALL);
- zakaznikovi davat: error_reporting(0);
Vychozi nastaveni (asi E_NOTICE) je prasarna. Skoda, ze spousta PHPkaru bere zakladni nastaveni jako zaklad a nastaveni maximalni uroven povazuje za zbytecnou buzeraci.
Dalsi vtipne veci se v PHP daji provadet s register_globals=on, ale to je pomerne znama pohadka.
Lukáš Lánský (neregistrovaný)
13. 7. 2004 16:05
Re: - (OT)
Áha... Zajímavé.
O Register globals vím z doby, kdy se u Psa na fórech objevila poměrně velká bitka, protože se admini rozhodli je vypnout...
O Register globals vím z doby, kdy se u Psa na fórech objevila poměrně velká bitka, protože se admini rozhodli je vypnout...
Michal Kubeček (neregistrovaný)
13. 7. 2004 18:26
Re: - (OT)
Nastavení
error_reporting = E_ALL by mělo být i na produkčním serveru. Jen to chce nastavit display_error = Off, aby se ty hlášky nezobrazovaly na stránce ale jen do logů. A samozřejmě se čas od času do těch logů podívat.
Mormegil (neregistrovaný)
13. 7. 2004 18:25
Re: -
Proboha jaky zkreslovani skutecnosti? Faktem je, ze v PHP nedelam (az na par trivialnich a zcela ne-mission-critical programku), takze se v jeho konfiguraci opravdu nijak zvlast nevyznam (i kdyz o error_reporting vim). Jenze ono to IIANM hlasi teprve ve chvili pouziti, ne ve chvili "kompilace".
Hlavni pointa je ovsem v tom, ze PHP (a obdobne dalsi skriptovaci jazyky) maji velice vysokou toleranci vuci programatorovym chybam, coz vede k tomu, ze az ji programator udela (ne kdyz, vsichni delaji chyby), vsimne si ji hure/pozdeji, nez kdyby ho kompilator okamzite serval. (Osobni priklad: v jednom ze svych skriptu jsem si napr. po ne zrovna kratke dobe vsimnul, ze v jedne velice zridka vyuzivane vetvi programu pisu dice0 misto dice[0]. Jenze se to projevi az ve chvili, kdy se tahle vetev bude provadet, coz uz muze byt "u zakaznika", kde je error_reporting vypnuty.)
A samozrejme nejde jenom o nedeklarovane identifikatory, to byl nejjednodussi priklad. Stejne tak me IIRC necha PHP do jedne promenne chvilemi prirazovat cisla, chvilemi retezce a pote z ni udelat pole. Atd. atd. Nikomu nenutim jazyky se striktnimi kontrolami jako zasadne lepsi, ale to, ze se takhle jazyky daji delit a ze to nejake vyhody ma, to snad uznavaji vsichni, ne?
Hlavni pointa je ovsem v tom, ze PHP (a obdobne dalsi skriptovaci jazyky) maji velice vysokou toleranci vuci programatorovym chybam, coz vede k tomu, ze az ji programator udela (ne kdyz, vsichni delaji chyby), vsimne si ji hure/pozdeji, nez kdyby ho kompilator okamzite serval. (Osobni priklad: v jednom ze svych skriptu jsem si napr. po ne zrovna kratke dobe vsimnul, ze v jedne velice zridka vyuzivane vetvi programu pisu dice0 misto dice[0]. Jenze se to projevi az ve chvili, kdy se tahle vetev bude provadet, coz uz muze byt "u zakaznika", kde je error_reporting vypnuty.)
A samozrejme nejde jenom o nedeklarovane identifikatory, to byl nejjednodussi priklad. Stejne tak me IIRC necha PHP do jedne promenne chvilemi prirazovat cisla, chvilemi retezce a pote z ni udelat pole. Atd. atd. Nikomu nenutim jazyky se striktnimi kontrolami jako zasadne lepsi, ale to, ze se takhle jazyky daji delit a ze to nejake vyhody ma, to snad uznavaji vsichni, ne?