Příspěvky

466

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 13. 10. 2019, 17:07:37 »

Kód: [Vybrat]

function atomicFuse($n, $c, $disableDelay = false){
  $start = false;
  if ( !file_exists("$n.t") ) 
   $start = mkdir("$n.t");
   ...

Zkus ten mkdir použít takhle:

Kód: [Vybrat]

if (@mkdir("$n.t")) {
    // akce
    rmdir("$n.t");
}

Vyloučíš tím kolizi.

467

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 13. 10. 2019, 15:50:25 »

Můžeš mi prosím napovědět k čemu ten výsledek testu je? O čem ty čísla svědčí ve vztahu k tvému úvodnímu příspěvku?

K čemu je procházení slepými uličkami? K ověření, že jsou slepé. Nejspíš to nikde neuplatní, ale během těch testů se toho dost naučí o chování souborových systémů a v budoucnu nebude vyjevený z nějakých kolizí.

468

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 22:14:37 »

Dík za článek. A proč prostě soubor nepřejmenovat?

Přejmenování se pro docílení atomicity skutečně používá. V daném případě musíš ještě ošetřit situaci, kdy proces přejmenuje soubor a následně chcípne. Co teď?

469

Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?

« kdy: 12. 10. 2019, 22:07:49 »

Variantu 1 jsem používal v éře PHP3, ale dnes bych ji už nepoužil, protože PHP a HTML nemíchám.

Variantu 2 nemá význam používat s Nowdoc, to bych raději tu šablonu načetl z disku. Opět z důvodu, aby se PHP nemíchalo s HTML.

I po této úpravě to stále vypadá složitější než ta první. Co jiného čekat v primitivním příkladu?

Pokud to však bude běžný web či ERP, bude mít druhé řešení navrch. Proč? Kodér například vytvoří novou šablonu, kde menu nebude nahoře, ale vlevo nebo dole. Pokud zachová ID, tak programátor nemusí změnit ani písmenko. U první varianty to však celé bude muset překopat.

Na drobnosti se však první varianta hodit může.

470

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 20:57:00 »

Například načtení konfigurace, šablony, slovníku nebo číselníku; uložení vygenerovaného obrázku, sitemapy, PDF, konfigurace a kdovíčeho ještě. Když ukládáš pod unikátními názvy, tak kolize nehrozí.

471

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 20:37:31 »

Díky moc za odpovědi. Moc jsem se poučil a teď už mám klid. Takže teď už vím, že file_get_contents a file_put_contents jsou vlastně k ničemu. Neumím si představit k čemu bych je využil, když existuje riziko, že dva lidé odešlou do stejného souboru data, ale uloží se jen jeden, ten druhej ne. Je to úleva.

PS: Tys nikdy nedělal kočku v mikrovlnce? 

Nejsem Alf

Ty dvě funkce jsou nejužitečnějsí ze všech funkcí, které pracují se soubory. Nemohou za to, že je používáš špatně pro naprosto nevhodný účel.

472

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 20:16:26 »

Zajímavé je ale to, že v manuálu těch funkcí není nic o tom, že data jsou bufferované.

Myslím že ten rozdíl v rychlosti T2 a T3/T4 dokazuje, že T3 a T4 neprovádí bezpečné čtení a zápis.

Nedokazuje to vůbec nic.

Ale jo, dokazuje to přesně to co si říkal. Je totiž z toho patrné, že ty data se nečtou z disku (rozuměj - z plotny), ale z bufferu.

Buffery jsou záležitostí souborového systému, proto v manuálu PHP nesmí o nich být žádná zmínka. Jsou transparentní. Je úplně jedno, zda se data čtou z plotny nebo ze systémové cache. V obou případech se jedná o čerstvá data.

473

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 20:10:54 »

Problém je, pokud soubor přečteš, modifikuješ a uložíš. Tyto tři úkony nejsou v jedné transakci a proto při souběhu můžeš přijít o data.

Díky. To mi bohatě stačí. Proč ale tyto informace nejsou uvedeny v manuálu. To je přece důležitá informace. Když do googlu zadám např. "php file_get_contents you can lose data" tak nenajdu nic s tímto výskytem. Takže očividně se tato informace tají. Jak jinak si vysvětlit, že před tímto nezbytným faktem nevarují?

Toto není nic, co by se tajilo. Je to základní vlastnost souborového systému, kterou by každý programátor měl znát. Týká se to všech programovacích jazyků, nejen PHP.

Kočku do mikrovlnky také nestrkáš, i když to v návodu není.

Doporučil jsem ti databázi proto, že umí zamknout nejen celý soubor, ale třeba jen kousek se záznamem, který chceš modifikovat. Umožní ti to modifikovat data třeba z deseti procesů současně, aniž by se mezi sebou popraly. Můžeš také jednu databázi sdílet třeba s deseti webovými servery. U fyzických souborů jsi bez šance na spolehlivé řešení.

K čemu potřebuješ v PHP práci se soubory?

474

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 18:46:58 »

Myslím že ten rozdíl v rychlosti T2 a T3/T4 dokazuje, že T3 a T4 neprovádí bezpečné čtení a zápis.

Nedokazuje to vůbec nic.

475

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 18:45:07 »

Nevím sice, o co se pokoušíš, ale obávám se, že ses vydal chybnou cestou. Pokud ti dělají starosti kolize, měl bys použít databázi, která se o takové problémy sama postará a k tomu ti nabídne luxusní přístupové metody. PHP v základní výbavě nabízí 5 různých databází, ze kterých si určitě vybereš.

Takže co je účelem zkoumání čtení a zápisu souborů? Konfigurace, blog, diskuzní fórum, ... ?

Takže přiznáváš, že u funkcí file_get_contents a file_put_contents existuje riziko kolize. Protože z tvého příspěvku to vyplývá. Se stejným přístupem mlžit a neříct to explicitně jsem se potkal na více místech internetu. To je ten důvod, proč jsem se vydal tou cestou, abych to prozkoumal. Jestliže považuješ file_get_contents a file_put contents za natolik nespolehlivé, že chceš raději používat databázi, nepřímo mi tím potvrzuješ výsledek mého zkoumání. Ale chtěl bych to slyšet explicitně, něco jako "Ano, už to tak asi bude" nebo "Z výsledků to vyplývá" nebo "Nevěřím tomu, jdu si to ověřit"... To je taky možnost.

Nejde o kolizi těchto dvou funkcí, obě jsou atomické a spolehlivé. Problém je, pokud soubor přečteš, modifikuješ a uložíš. Tyto tři úkony nejsou v jedné transakci a proto při souběhu můžeš přijít o data. Pokud potřebuješ takový případ užití, použij databázi.

Uvědom si, že se vlastně sám snažíš vytvořit databázový engine, tedy vynalézáš kolo. Mnoho databází vypadá jako obyčejný textový soubor, ale ten engine nad nimi je už hotový a odzkoušený. Proč některý z těch pěti nepoužiješ? Chápu, že třeba nechceš použít MySQL, ale co ty ostatní? Zkusil jsi někdy nějakou databázi? Jsou tady proto, aby nám sloužily.

476

Vývoj / Re:Jak se chránit pro XSS útoku na php serveru?

« kdy: 12. 10. 2019, 18:24:55 »

DOMDocument je možná bezpečnější, ale to "lepší" se mi moc nezdá (spotřeba paměi,výkon,nutnost kompletního DOMu před odesláním na clienta).
Navíc transformace DOMu se dost liší od běžného použití php jako preprocesoru. To už mi přijde "lepší" použít nějaký framework, než toto.Ale to už jsme mimo téma.

Příznivci funkcionálního programování zde mají příležitost, jak se vyřádit. Nutnost kompletního DOMu nevidím jako překážku, jen málo úloh při tom vyžaduje víc než 1 MB. Obvykle to jsou jen desítky až stovky KB, se kterými si hravě poradí v malých jednotkách ms. Odezva je tedy řádově rychlejší než u běžných frameworků. Pokud bys ten DOM nechtěl generovat naráz, tak nemusíš. Uděláš jednu větev, exportuješ, uděláš další, exportuješ,... Efektivnější je však vygenerovat vše naráz, nemusíš tak plýtvat drahým echem. Po odladění jen vypneš odsazování. Navíc se v XML, které dostaneš navíc jako bonus, hledají chyby mnohem snáze než v HTML.

Mno, asi máš pravdu, ale pořád se nemůžu zbavit dojmu že u projektů kde bych uvažoval takhle přímo psát v php je to kanón na vrabce, a jde to proti "duchu" php, jak ho chápu já, cožje víceméně preprocesor pro html s možností doplnit o nějaký ten kód, čtení z db atp.

Naopak se mi jeví generování XML a HTML přes DOM velmi snadné a elegantní. V žádném případě se nejedná o kanón na vrabce. Dokonce můžeš importovat statické HTML, změnit libovolné nody a poslat na výstup v podstatě stejně jako v Javascriptu. Všechny šablonovací systémy se proti takové jednoduchosti použití mohou zahrabat. Kodérovi stačí, pokud umí HTML a Javascript.

V PHP si zpracuji vstup, načtu či modifikuji data v databázi, načtu šablonu, vložím do ní data, vyplivnu na výstup a hotovo. Vše má PHP v základní výbavě, frameworky nejsou potřebné. Je dobré, pokud použiješ architekturu MVC a budeš se držet zásad SOLID, které bývají ve frameworcích tak často porušovány.

477

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 17:06:21 »

Nevím sice, o co se pokoušíš, ale obávám se, že ses vydal chybnou cestou. Pokud ti dělají starosti kolize, měl bys použít databázi, která se o takové problémy sama postará a k tomu ti nabídne luxusní přístupové metody. PHP v základní výbavě nabízí 5 různých databází, ze kterých si určitě vybereš.

Takže co je účelem zkoumání čtení a zápisu souborů? Konfigurace, blog, diskuzní fórum, ... ?

478

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 16:50:27 »

Souborové systémy mají vlastní buffery a cache. Zkus z jednoho procesu neustále modifikovat jeden soubor a z druhého ho číst. Uvidíš, že je to spolehlivé.

V T2 máš chybu

Kód: [Vybrat]

$s = file_get_contents("523");

Tohle čte ze souboru, který zřejmě neexistuje.

479

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 16:05:06 »

Ještě bych k tomu dodal, že pokud ty funkce používají buffering na úrovni souborového systému, což předpokládám, není nutné se obávat nespolehlivosti a nekonzistence. Ukaž příklad, kdy k něčemu takovému došlo a rozebereme příčiny. Bez zámků se to stává jen u souborů >8 KiB.

480

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 12. 10. 2019, 15:50:11 »

Jako třetí parametr file_put_contents() zkus uvést konstantu LOCK_EX

Používám téměř výhradně tyto dvě funkce, ostatní jsem odstavil jako nepotřebné. Výsledky po úpravě volání mě zajímají.