Starší komentáře ke článku: Konfigurační soubor v PHP ve formátu XML
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 16.10.2003 10:02:58
Kdyz takhle udelam konfiguraci, tak jak moc se casove zpomali vykon aplikace?
Datum vložení: 16.10.2003 10:47:56
Je otazkou, zda neni vyhodnejsi pouzit nativni PHP funkci parse_ini_file a zapisovat konfiguracni soubory ve formatu INI souboru. Pro nativni funkci bude hrat nejspise rychlost (nezkousel jsem).
Datum vložení: 16.10.2003 11:38:11
Rozdíl v rychlosti nebude příliš velký. Použití XML je výhodné kvůli jeho univerzalitě, např. zobrazení konfigurace v přehledné HTML podobě je otázkou třířádkového skriptu (a napsání příslušné XSLT transformace). A hlavně to přináší možnost použití složitěji strukturovaných dat v konfiguraci, aniž by se tím parser neúnosně komplikoval. V tom případě by ale asi bylo pro parsing XML souboru vhodnější použít DOM XML (libxml2) než expat.
Datum vložení: 16.10.2003 16:41:48
A pokud nemate dostupny libxml2, tak se pak jako dalsi varianta jevi vytvoreni vlastniho parseru pres regexpy.... Je to pak rychlejsi v parsingu nez expat a mozna i libxml2.
Datum vložení: 9.8.2006 23:37:47
Omlouvám se redekci za zdržování.Nechci reagovat,ale pouze se zeptat v jakém PGMu mohu otevřít sooubor ve formátu XML. Děkuji
Datum vložení: 16.10.2003 18:49:01
Konfigurace pomocí XML je myslím správná cesta, ale je potřeba si uvědomit, že není možné takto konfigurovat úplně vše. Do konfigurace většina programátorů ukládá třeba uživatelské jméno a heslo k databázovému serveru. Pokud by tyto údaje dali do XML a XML by bylo ve webovém prostoru, tak je možné v určitém případě si tyto údaje zobrazit do prohlížeče. V tomto případě to může být obdobné jako použití .inc souborů bez mapování přípony inc na php.
Datum vložení: 16.10.2003 19:23:41
To je ale přeci naprosto nezávislé na formátu toho konfiguračního souboru. Ať už použijete XML, obyčejný text nebo cokoli jiného, problém je pořád stejný.
Datum vložení: 16.10.2003 21:24:54
No tak to tedy není. Pokud budu mít soubor conf.xml a v něm:
<conf>
<const name="heslo">mojeTajneHeslo</const>
</conf>
a nebo conf.php a v něm:
define("heslo", "mojeTajneHeslo");
tak co se stane, když napíšu:
<a href='http://www.domena.cz/conf.xml' target='_blank'>http://www.domena.cz/conf.xml</a>
a co když:
<a href='http://www.domena.cz/conf.php' target='_blank'>http://www.domena.cz/conf.php</a>
to je ten rozdíl.
Datum vložení: 16.10.2003 21:31:59
Není. Rozdíl je v tom, zda obsah toho souboru zpřístupníte prostřednictvím webu klientům. Ne ve formátu toho souboru. Obsah souboru může být přístupný nebo nepřístupný bez ohledu na to, zda je to PHP nebo XML.
Datum vložení: 16.10.2003 21:53:09
sorry, ale tvoje pripominky jsou zcestne. haugh.
Datum vložení: 16.10.2003 22:17:21
Protože jste nejspíš vůbec nepochopil, o čem mluvím, zkusím to trochu rozvést. Především nevidím naprosto žádný důvod, proč by konfigurační soubor měl být v adresáři, jehož obsah je prezentován webovým serverem klientům. Ale i kdyby snad ano, pořád ještě mícháte dohromady tři různé věci:
1. co je obsahem souboru, tj. v jakém je formátu
2. jak vypadá jméno souboru
3. co server udělá, pokud o něj bude požádán
Zda bude mezi body 1 a 2 nějaká souvislost, záleží čistě na vás. Nikde totiž není specifikováno, že jméno souboru, jehož obsahem je XML, musí končit řetězcem '.xml'. Naopak, většina XML souborů tím nekončí. Zapomeňte, prosím, na přípony, pokud nepoužíváte DOS s jeho 8+3 jmény. Když to přeženu, můžete ten konfigurační soubor pojmenovat třeba config.php, server se ho pokusí interpretovat jako PHP skript, skončí chybou parseru na prvním řádku a nezobrazí vůbec nic. A máte to zadarmo.
Druhá věc je souvislost mezi body 2 a 3. To opět záleží na vás, stejně jako Apache ve standardní konfiguraci nezobrazuje klientům soubory, jejichž jména začínají na '.ht', je práce asi tak na půl minuty zavést podobné pravidlo, které zakáže zobrazování souborů jménem 'config.xml'. Totéž platí o jakémkoli jiném jménu.
Zdá se mi poněkud neslušné odbýt dobře míněná vysvětlení někoho, koho ani neznám, bez přemýšlení slovem "zcestné". Takže vám nebudu oplácet stejnou mincí, pouze vás poprosím, abyste si pozorně přečetl, co jsem vám tu teď napsal, a zkusil se nad tím zamyslet. Třeba vám to někdy pomůže nepodléhat zkratkovitým soudům. Existuje ještě mnoho dalších způsobů, jak zajistit, že konfigurační soubor nebude klientovi zobrazen. V každém případě trvám na tom, že vůbec nezáleží na jeho obsahu, ať je to PHP nebo HTML, může být zobrazen nebo nemusí, záleží jen na tom, jak si to zařídíte.
Datum vložení: 17.10.2003 11:05:53
Ja netvrdim, ze rikate neco spatne, ale ze je zcestna vase pripominka k memu prispevku. Chtel jsem jen upozornit na to, ze pokud nekdo vyuzije konfigurace pomoci XML popsanou v clanku, tak by si mel uvedomit, ze to muze byt vazne bezpecnostni riziko, pokud by napriklad nevyuzil moznosti, ktere jste popsal. Tot vse.
Ale i tak k vasim "trem bodum". Pokud zabezpecujete svoje skripty tak, ze spolehate, ze parser vyhodi error, tak to se nemame o cem bavit.
Samozrejme pokud se zvoli pro konfiguracni soubory specialni pripona, dejme tomu .xcf, ktere se zakaze read na webserveru, tak ok - takto je resena treba konfigurace v asp.net. Toto ale vyzaduje mit vlastni server (tj. ne webhosting).
A jeste - ze se konfiguracni soubory umistuji do webrootu, je velice caste, vetsina lidi je dava do adresare, ktery nazyvaji /inc/. Nektere webhostingy totiz vubec neumoznuji dat neco mimo webroot.
Datum vložení: 17.10.2003 13:06:35
Ale já přeci nezabezpečuji skripty tím, že bych spoléhal na chybu parseru. Pouze jsem uvedl, jako poněkud extrémní eventualitu, že XML konfigurační soubor může klidně mít i "příponu" php. A že pak parser skutečně skončí hned na prvním řádku, na to se můžete spolenhnout: přes XML deklaraci prostě nemá šanci projít... A i nadále mi nezbývá než trvat na tom, že bezpečnostní problém je čistě v tom, zda obsah konfiguračního souboru zpřístupníte klientovi, což nijak nesouvisí s tím, jakém je formátu. To jsem napsal hned na začátku a vám se to tak hrubě nelíbilo.
Datum vložení: 5.5.2006 14:22:52
nevim sice, jak presne je problem resen na .net platforme, ale apache umoznuje menit vetsinu nastaveni serveru za behu pomoci souboru .htaccess, a to az na uroven jednotlivych souboru nebo masek. nastaveni navic kaskaduje do podadresaru, takze zabezpeceni konfiguracnich souboru pro cely web znamena tri radky: <Files ~ "\.(ini|xcf|inc)$"> deny from all </Files> To rozhodne nevyzaduje 'mit vlastni server', ani 'dat neco mimo webroot'. Pokud web bezi na apachi a webhosting konfigurovani pomoci .htaccess neumoznuje, je namiste ZMENIT POSKYTOVATELE nebo PRIPLATIT.
Datum vložení: 5.5.2006 20:49:08
Platforma .Net nabízí podobně jednoduché řešení a .htaccess funguje i na IIS, takže v tom bych problém neviděl ;-)
Datum vložení: 27.10.2003 9:57:13
No pokud jde o ty hesla, proc jako treba nepouzit MD5? Napriklad:
<conf>
<const name="uzivatel" encoded="PLAIN">kremik</const>
<const name="heslo" encoded="MD5">(MD5_hesla)</const>
</conf>
Datum vložení: 10.12.2003 15:03:02
obavam se, ze MD5 je nedostatecne, neni totiz problem na dostatecne rychlem stroji vygenerovat pouzitelnou frazi behem pomerne kratke doby. to uz ale hovorime o metodach utoku zalozenych na "brute force", neboli pouziti hrube sily.
Datum vložení: 25.10.2005 21:33:25
To je sice dobra myslenka, ale kdyz si udelate hash hesla pro pristup k databazi (ktere bude v tomto konfigurancim souboru), jak ho pak dostanete zpatky abyste ho mohl pouzit?
Datum vložení: 2.7.2006 10:14:37
Co když je ovšem element prázdný? Hází to chybu.