| Autor | Zpráva | ||
|---|---|---|---|
| Gray blogger Profil * |
#1 · Zasláno: 24. 9. 2019, 06:59:24
Četl jsem tenhle článek o zamykání ale moc to nechápu:
www.hackingwithphp.com/8/11/0/locking-files-with-flock Můžete mi to vysvětlit co dělá ten kód? <?php
$fp = fopen( $filename,"w"); // open it for WRITING ("w")
if (flock($fp, LOCK_EX)) {
// do your file writes here
flock($fp, LOCK_UN); // unlock the file
} else {
// flock() returned false, no lock obtained
print "Could not lock $filename!\n";
}
?>Proč tam je ta podmínka if, tenhle kód mi nedává smysl. čekal bych něco jako 1. fopen 2. lock the file 3. add data to file (if it's locked) 4. release the lock A z těch dalších kódů na stránce jsem taky jelen. Proč tam dává sleep? |
||
| blaaablaaa Profil |
#2 · Zasláno: 24. 9. 2019, 08:12:02
Gray blogger:
flock vrací true v případě úspěchu. Tedy Pokud se flock povedl, uděláš s ním, co potřebuješ a uvolníš zámek. Pokud se zamknout nepovedl, pak vypíšeš hlášku. Sleep v ukázce jen je ze studijních účelů, aby šlo vidět, že je soubor po dobu 10s zamčen, v textu je přesně vysvětleno, co příklady dělají. |
||
| Gray blogger Profil * |
#3 · Zasláno: 24. 9. 2019, 08:34:01
Co tedy znamená pokud se flock nepovedl? Znamená to, že soubor je nepřístupný, tedy zamknutý jiným zkriptem, na souboru se pracuje?
|
||
| blaaablaaa Profil |
#4 · Zasláno: 24. 9. 2019, 09:15:33
Gray blogger:
Ano, přesně jak je psané v tom článku a poslední příklad to i v praxi ukazuje. Ale vše je tam krásně vysvětlené, chce to nejdřív číst, vyzkoušet a až pak se ptát. |
||
| Gray blogger Profil * |
#5 · Zasláno: 24. 9. 2019, 09:51:07
blaaablaaa:
Jak říkám, mě ten článek srozumitelný není. Podle mě je to jedno z nejhorších vysvětlení vůbec. Tahle věc na kterou se ptám tam vůbec vysvětlená není. Pokud někdo chce psát články tak by si měl ujasnit pro koho ho píše, jestli pro někoho kdo o tom nic neví nebo pro někoho kdo už ty věci umí. |
||
| blaaablaaa Profil |
#6 · Zasláno: 24. 9. 2019, 09:55:29
Gray blogger:
Chyba nebude v článku. Vše je tam jednoduše popsané, jsou tam základní ukázky (okomentované), které si každý může vyzkoušet (a pokud je i na to líný, má tam přesně napsané, jak se skript bude chovat). |
||
| Dash Profil * |
#7 · Zasláno: 25. 9. 2019, 10:57:31
Ten příklad není moc dobrý. PHP bude u jinde zamčeného souboru pro LOCK_EX čekat na odemčení (nevrátí false). False výstup nastane v případě nějaké chyby, nejčastěji na úrovni systému, v praxi málokdy.
|
||
| blaaablaaa Profil |
Dash:
V odkaze tam pak je i příklad s LOCK_NB, na kterém demonstruje "zamčenost" souboru a smysl té podmínky. |
||
| Gray blogger Profil * |
#9 · Zasláno: 25. 9. 2019, 11:45:57
Dash:
Dík za přínosnou reakci. blaaablaaa: Každému vyhovuje něco jiného, to máš s hodnocením úplně všeho ať jde o knihu, film nebo článek, každému vyhovuje jiný přístup a každý má jiný druh paměti. Mě by spíš vyhovovala praktická ukázka s tím jak zapisuje ty data do souboru a dá tam smysluplnou hlášku, ale to si ještě prohledám internet. |
||
|
Časová prodleva: 12 dní
|
|||
| Gray blogger Profil * |
Dnes jsem našel stránku, kde je to dobře vysvětleno na otázce jak testovat zámek:
What does LOCK_NB mean in flock? Dobře je to vysvětleno i v komentářích, jen mi ještě není jasné co znamená argument would block. Co znamená "if the lock would block"? K čemu je dobrý tento argument, když otestování jestli je zamčen lze provést pomocí ! flock($f, LOCK_NB) Tak ještě mám dotaz - znamená to, že toto je dobré řešení? $s = 0;
while ( ! flock($f, LOCK_NB) ) {
usleep(200);
$s++;
if ($s==15)
break;
}V situaci, kdy např. chci odeslat vzkaz uživateli ... Je přihlášeno např. 10-20 lidí, kteří si ale mohou mezi sebou psát. Když by posílali dva lidi současně stejnému uživateli zprávu (případně by si dva uživatelé ve stejný čas vyměnili zprávy) a nastala by tato situace, že soubor je jedním uživatelem zamknut v době kdy zapisuje data. Je to tedy lepší než mu zobrazit zprávu: "momentálně nelze odeslat zprávu, zkuste to o vteřinu později..." ... Poslal jsem nesprávný link, tenhle se mi líbil více: Test if file is locked |
||
| Tomášeek Profil |
#11 · Zasláno: 7. 10. 2019, 18:18:42
Gray blogger:
Sorry, ale řešíš tu dokola pořád nějaký číčoviny. Nebylo by snažší a rychlejší fakt investovat ten samý čas do základu SQL dotazů? Už by ti ta tvoje aplikace dávno fungovala a neměl bys před sebou ještě další milion problémů, které ti práce se soubory přinese. |
||
| Gray blogger Profil * |
Tomášeek:
Ne, nebylo. Nefungovala. Zjednodušuješ. Kdysi dávno jsem se na to už dávno díval a to není jen o tom přečíst si dva tutorialy, je to taky o bezpečnosti a správě dat na databázi. Samozřejmě taky omezená kapacita na webhostingu zdarma, kde je 20MB prostoru. Prostě SQL je zabiják času a není to řešení pro mě. MySQL je mnohem složitější než se to tu snažíte prezentovat. Je třeba znát správný formáty, klíče, náhledy atd. A jako co že bych investoval čas do základů SQL, myslíš že PHP se za mě naprogramuje samo nebo jak? Ty mi přijdeš jak nějaký podobní prodejce co mi furt cpe nějaký zboží, fakt to nemá cenu. Ale ujišťuji tě na reklamy a různé moderní výstřelky jsem fakt dobře odolnej. Nechci z tohoto topicu udělat diskusi, ale včera večer jsem nad tím přemítal jaká plýtvárna času je mysql, phpmyadmin a všechny tyhle klikací srandičky. Furt na něco čekat, něco hledat a čumět do bílého monitoru... Já si to raději pěkně najdu v jednom souboru otevřeném v PSPadu a mám to všechno na jednom místě, pěkně v textových souborech, kde vše lze snadno najít. To hledání textu není přes MYSQL příkazy, ale cvak cvak na klávesnici f3 a mám to. |
||
| RastyAmateur Profil |
Nauč se SQL.
Gray blogger: „Já si to raději pěkně najdu v jednom souboru otevřeném v PSPadu a mám to všechno na jednom místě“ A uvědomuješ si, že když to máš takhle hezky v nějakém souboru otevřeném v PSPadu, že ta data pak musíš také nějak rozparsovat? A uvědomuješ si, že to parsování děláš ty a na úrovni PHP? A uvědomuješ si, že to parsování na úrovni PHP je neskutečně pomalé? A uvědomuješ si, že ty beztak nahraješ do paměti celý soubor s daty a vybereš si z toho jen nějakou část? Mám pocit, že jsi v jiném vlákně nadával, že SQL je strašně pomalé... Kdyby jsi ten tvůj megastrašněnejvícgigamoc drahocenný čas, který strávíš hledáním informací o zámcích, parsování, práci se soubory a podobnými hovadinami strávil tím SQLkem, už bys to měl dávno hotové. „Samozřejmě taky omezená kapacita na webhostingu zdarma, kde je 20MB prostoru.“ Mně to vždy stačilo, a to bohatě. By mě zajímalo, co tvoříš ty za aplikaci, že to má o tolik více dat. O to víc mě to zajímá, když jsi naznačil, že to děláš v PSPadu. „jaká plýtvárna času je mysql, phpmyadmin a všechny tyhle klikací srandičky.“ Lol, ty klikací srandičky přeci používat neumíš. Sice tvorbu tabulky to zrychlí třeba desetinásobně, ale v pohodě, můžeš si na to napsat vlastní SQL, který další hodinu budeš ještě odlaďovat a debugovat... Mně se strašně líbí jedna věc. Ty tu nadáváš, jak je SQL složité nebo co. Přitom SQL byl vytvořený tak, aby vlastně odpovídal normální mluvě, normální angličtině. Proto je (alespoň na té základní úrovni) tak strašně jednoduchý a lehce naučitelný. Protože příkaz create table ezpz nebo select username from users where id = 123 pochopí snad úplně každý...
„Ty mi přijdeš jak nějaký podobní prodejce co mi furt cpe nějaký zboží, fakt to nemá cenu. Ale ujišťuji tě na reklamy a různé moderní výstřelky jsem fakt dobře odolnej.“ Škoda, on se ti jen snaží pomoct. Neprodává vysavače za účelem zisku. Ale ve svém volném čase se snaží pomoct lidem. „je to taky o bezpečnosti“ Jediné, co by bylo fajn řešit, je SQL Injection. Jinak si myslím, že nic jiného ohledně bezpečnosti řešit v SQL narozdíl od souborů nemusíš. Spíš si naopak myslím, že bys měl více věcí ohledně bezpečnosti při práci se soubory... |
||
| Gray blogger Profil * |
#14 · Zasláno: 7. 10. 2019, 19:39:43
RastyAmateur:
Tak ono pomalé opravdu je a to hlavně na takových redakčních systémech jako wordpress. Kdysi jsem zkoušel různé RS a s webem, který je dělaný na bázi souborů se to nedalo vůbec srovnávat. Zatímco RS požadavky se vyřizovali v řádu sekund na souborovém systému se data načítali okamžitě. Mám radši nízkoúrovnové programování a se vším si dovedu poradit. Konkrétní návody tu nebudu poskytovat, protože bych zase sklidil jen posměch, pohrdání ... Aktuálně můj projekt nebude zahrnovat stovky uživatelů a zatím teprve pracuji na registraci uživatelů. Podle toho jestli se to osvědčí nebo neosvědčí se pak budu rozhodovat jakým způsobem dál budu řečit případný vzkazník. " .. už bys to měl dávno hotové." Opakuji, že neměl, protože tolik volného času nemám. Občas do něčeho šťouchnu a ty php příkazy na práci s db se samy nenapíší. Ono to tak jednoduché není, není to jen SQL. Jsou to sql příkazy jako SELECT, JOIN atd. a zpracovávání proměnných, je tam nějaká logika, jako zpětná kontrola dat atd. a to vše je třeba naprogramovat stejně tak jako když člověk pracuje s txt souborem. Tímhle směrem se už znova ubírat nebudu. Aktuálně se chci věnovat jen php, občas šťouchnout do html nebo css. Žádný vytuněný design, žádný SQL, prostě jen nejnutnější věci. Je fajn že si zvědavý, ale je ti doufám jasný, že vzhledem k vašemu přístupu se nebudu s vámi sdílet o svých plánech. Něco jiného by bylo kdyby tu byl nějaký nadšenec do nízkoúrovňového programování a txt, ale nenajdeme společnou řeč. Jak víš, že ty klikací srandičky neumím používat? Právě, když ladíš musíš furt na něco klikat a když ty data zadáš špatně, musíš to pak zase mazat nebo updatovat atd. Prostě fuj! Tak jo, zkus se bavit třeba s češtinářkou jazykem SQL, když je to tak podobné české mluvě hahaha. Nebo zajdi do obchodu a zkus to a poděl se o zkušenost jak ti lidé rozuměli. Právě SQL injection je to co na txt řešit nemusím, žádné html entity a jejich převody... Je to jednoduché. |
||
| tttt Profil * |
#15 · Zasláno: 7. 10. 2019, 20:54:02
Gray blogger:
Důvod, proč se nepoužívají soubory je, že jsou pomalé (zamkneš vždy celou "databázi") a že není jednoduché ošetřit*, abys nehrozilo, že přijdeš o data. To první ti nejspíš nevadí, jestli máš míň jak deset uživatelů. To druhé dost možná taky ne, půjde předpokládám o nějaký hobby projekt. U čekokoliv serióznějšíhoto to takhle nejde. Právě SQL injection je to co na txt řešit nemusím Používáš zřejmě nějaký vlastní formát, který podobně jako SQL bude náchylný na vložení speciálních znaků (konců řádků, oddělovačů atp.). Chceš-li to mít bezpečné, musíš to taky řešit. A dokonce si ten kód na ověřování musíš psát sám, což je práce navíc, a náchylné k chybám. žádné html entity a jejich převody Nezáleží na tom, kam to ukládáš, tohle musíš řešit všude, jinak ti někdo může rozbít vytvořené HTML stránky. * Vzhledem k tomu, že jsi zrovna začal zkoumat zamykání, tak mimo tvé znalosti. |
||
| Tomášeek Profil |
#16 · Zasláno: 7. 10. 2019, 21:52:17
Gray blogger:
Hele, je to tvůj boj, dělej si, co chceš. Musím přiznat, že by mě docela zajímalo, jakým způsobem se ti podaří nahradit kompletní funkčnost databáze, jak ošetříš zámky a vůbec bezpečnost souborů pro stovky uživatelů, ... Autentizace uživatelů, oprávnění přístupů, atd., to bude bašta na úrovni souborů, navíc od člověka, který s tím vším začíná. Kdybys sem dal URL, pokusil bych se jí zapamatovat, protože jsem si jistý, že ten projekt nespatří světlo světa. A za tebe doufám, že těch uživatelů fakt nebudou stovky, jak jsi psal, už jen kvůli té nebezpečnosti, která z toho kouká. „je ti doufám jasný, že vzhledem k vašemu přístupu se nebudu s vámi sdílet o svých plánech.“ Škoda, že to neaplikuješ i na své dotazy. „Právě SQL injection je to co na txt řešit nemusím, žádné html entity a jejich převody...“ Aha, tak to jo. Jasně, asi se tomu nebude říkat SQL injection, když to není v SQL, že? Ale princip útoku a jeho ošetření bude stejný. |
||
| Keeehi Profil |
Gray blogger:
Průser tvého lowlevel programování je, že si VŠECHNO musíš napsat sám. Například teď se snažíš implementovat vlastní ACID což v MySQL máš zdarma. Předpokládejme tvé řešení kde zamkneš soubor pro jednoho uživatele. Náročnost čtení je pak u×1 kde u je počet uživatelů. U databáze je to 1, jelikož podporuje paralelní přístup. Takže s rostoucím počtem uživatelů to začne být čím dál tím pomalejší. Podívejme se teď na to, jak počet záznamů n ovlivní rychlost vyhledávání. Ty budeš muset vždy celý soubor načíst do paměti, sekvenčně ho projít, rozsekat na jednotlivé záznamy a v nich pak najít co potřebuješ. Náročnost bude něco jako k + n×1 + o. k je nějaká konstanta která reprezentuje diskové operace, n je počet záznamů a pod o schovám veškerou ostatní režiji, co je potřeba. Ještě vysvětlím že ta 1 reprezentuje jednu jednotku času kterou zabere projití jednoho záznamu a překontrolování toho, zda je to ten který hledáme. U databáze to vypadá k + log(n)*1 +o. k je zase nějaká konstanta, která tentokrát reprezentuje například rozparsování dotazu, optimalizace, plánování atp. k bývá v reálném světě oproti té jednotce času větší, ale žádný extrém to není. Řekněme třeba 1000. o se nebudeme zabývat, protože nám jde teď o to zjistit, jak se mění rychlost v závislosti na počtu záznamů. Pro soubor tedy máme tedy 1000 + n a u databáze 1000 + log(n). Pro sto řádků to je 1100 pro soubor a 1006 pro databázi. OK, to není takový rozdíl, pojďme dál. Pro tisíc řádků je výsledek pro soubor 2000, pro databázi 1010. No, to už je horší ale chápu že pro někoho kdo chce používat soubory nemusí být toto stále přesvědčivý argument. Co deset tisíc řádků? 11 000 ku 1013. Sto tisíc? 101 000 ku 1016. Když se k tomu přidá ještě to že u řešení se soubory jeden uživatel musí čekat na druhého, tudíž ta hroší výkonnost při hledání záznamů se ještě násobí počtem uživatelů tak nám z toho vychází, že to tvoje super-efektivní low-level programování vlastně až tak super efektivní vlastně není. „Právě SQL injection je to co na txt řešit nemusím, žádné html entity a jejich převody... Je to jednoduché.“ Ano, když nepoužíváš SQL tak opravdu SQL injection řešit nemusíš. Musíš ale řešit něco jiného. Říkejme tomu třeba Proprietary File Parse Injection. No a html entity a jejich převody musíš řešit vždy ať použiješ jako uložiště databázi, soubor, nebo cokoli jiného, jelikož s uložištěm to nemá vůbec co dělat. |
||
| Gray blogger Profil * |
Tam nebudou stovky uživatelů. Pro tvou zajímavost načtení 129kb obrázku a jeho opětovný zápis na webzdarma trvá 0.00036907196044922 s , tak jaké obavy o rychlost načítání dat? Schválně jsem udělal tenhle malý testík. No i kdyby těch uživatelů byli stovky, vždycky se dá najít jednoduché řešení. Například rozdělit velký soubor na menší soubory... Vytvořit rejstříky nebo indexy, nebo uložit hodnotu délky záznamu a s tím počítat při parsování.
Keeehi: No a když bych použil framework, tak se zase musím učit framework s čímž bych strávil spoustu času, nebo si mohu zase sám napsat všechno přes myslq, takže čas strávím tak či tak. Pro mě je spíš podstatné rozjet nejprve něco malého. Po měsíci programování to otestovat na ostrém provozu a když to pojede dobře a nebudou stížnosti, a pak zkusti přidat další funkcionalitu. Pokud se nepletu tak zamykat je třeba jen při zápisu. Pokud uživatel chce přihlásit a nenačtou se mu data, dostane chybu a může to skusit znova. Ale pravděodobnost chyby je snad hodně malá při této rychlosti kde se řeší desetiny milisekund. Při malých souborech se dá snadno zazálohovat soubor, takže kdyby přeci jen došlo k vadnému zapsání, porovnám velikost předtím a potom a vidím že se soubor zmenšil, došlo k chybě, je třeba ho obnovit... Sice je pravda, že pracuju s více soubory a musím řešit tyto "pojistky", ale jakmile je automatizace plně funkční, mohu si takový web naklonovat kolikrát chci... tttt: Jasně, Javascriptem, to znám :) To stačí zakázat znaky <, > ve vstupním textu. No já nevím, mě ty souborové přístupy nepřipadají pomalé. Pro rychlý přístup se musí pracovat s malými soubory. Tomášeek: Útok - jenže JS nenapáchá takovou škodu jako SQL dotaz. Navíc mysql databáze zaneřáděná spamy se fakt blbě promazává. Kdysi jsem dělal správce redakčního systému (který napsal někdo jiný) na úrovni administrátora, takže vím, že když RS není dobře ošetřený proti spamům taky může spadnout celý systém. |
||
| Keeehi Profil |
„Jasně, Javascriptem, to znám :)“
Ne neznáš. Ošetřování se musí dělat na serveru, dělat to po výpisu na stránku je už pozdě. „To stačí zakázat znaky <, > ve vstupním textu.“ Nestačí. V HTML kontextu mohou i uvozovky a apostrofy dělat problém. Navíc ve vstupním textu nejsou potřeba zakazovat. Je potřeba je enkódovat při výstupu, vždy právě ale podle kontextu. Takže v jiném, než HTML kontextu to mohou být úplně jiné znaky, které je potřeba ošetřovat. „No já nevím, mě ty souborové přístupy nepřipadají pomalé.“ Reálně ale jsou. Tedy záleží na jakém disku jsou data uložená, ale diskové operace jsou téměř to nejpomalejší co v počítači je. „jenže JS nenapáchá takovou škodu jako SQL dotaz“ Super vtip. Každý dělá něco jiného, ale jak SQL injection tak XSS můžou mít obří dopad. Ale ano, kdo tomu nerozumí, tomu může přijít javascript zase až tak nebezpečný není. „Navíc mysql databáze zaneřáděná spamy se fakt blbě promazává.“ Promazává se úplně stejně dobře jako soubor. Navíc se nemusíš bát, že by jsi přišel o nové záznamy mezi tím co to promazáváš. „když RS není dobře ošetřený proti spamům taky může spadnout celý systém.“ Mnohem pravděpodobnější to ale bude u toho tvého souborového RS. |
||
| Tomášeek Profil |
#20 · Zasláno: 7. 10. 2019, 23:12:37
Gray blogger:
„Pro tvou zajímavost načtení 129kb obrázku a jeho opětovný zápis na webzdarma trvá 0.00036907196044922 s , tak jaké obavy o rychlost načítání dat?“ Tak něco jiného je testovat rychlost čehokoliv lokálně a bez uživatelů a něco jiného na vzdáleném serveru a se stovkami uživatelů. „Pokud uživatel chce přihlásit a nenačtou se mu data, dostane chybu a může to skusit znova.“ :-) „Při malých souborech se dá snadno zazálohovat soubor, takže kdyby přeci jen došlo k vadnému zapsání, porovnám velikost předtím a potom a vidím že se soubor zmenšil, došlo k chybě, je třeba ho obnovit“ Zálohy, kontroly, obnovy... myslíš, že ty jsou zadarmo? Zbytečně plýtváš časem na testování něčeho, co by za tebe odtestovala mnohem rychleji databáze. „jenže JS nenapáchá takovou škodu jako SQL dotaz.“ Typ SQL a JS útoků je úplně jiný, mícháš jabka a hrušky. „Navíc mysql databáze zaneřáděná spamy se fakt blbě promazává.“ Jak se liší promázávání spamu v DB a jak v souboru? Databáze má výhodu, že jí rychlostně neomezí milion spamových záznamů. Mít milion spamu v souboru poznáš výrazně. „když RS není dobře ošetřený proti spamům taky může spadnout celý systém.“ Což platí i pro souborové přístupy, a myslím, že ve větší míře. |
||
| tttt Profil * |
#21 · Zasláno: 7. 10. 2019, 23:48:28
Keeehi:
Reálně ale jsou. Tedy záleží na jakém disku jsou data uložená, ale diskové operace jsou téměř to nejpomalejší co v počítači je. Tohle budou tak malé a často přistupované soubory, že budou nacachované v paměti. Načtení 1 MB ze SSD trvá 1 ms, načtení téhož z paměti 250 µs. Pochopitelně se to liší kus od kusu, ale nebude to lítat o řády. On nejspíš fakt nebude mít problém s rychlostí, jestli tam bude mít deset uživatelů. I ta databáze by na tabulká s pár desítkami záznamů dost možná dělala full table scany. Problémy nastanou, až tam bude mít těch uživatelů 100, pak to bude muset celé přepsat. Gray blogger Pokud se nepletu tak zamykat je třeba jen při zápisu. Určitě? Co se stane, když zapíšeš/přepíšeš soubor, který někdo zrovna čte? |
||
| Gray blogger Profil * |
Tomášeek
Tak něco jiného je testovat rychlost čehokoliv lokálně a bez uživatelů a něco jiného na vzdáleném serveru a se stovkami uživatelů. To nebylo lokálně, ale na wz. Tomášeek: Milion? To se nikdy nemůže stát. Protože to budu udržovat v různých souborech, takže pokud zjistím, že dotyčný odesílal spamy, jednoduše smažu jeden soubor a tím pádem je polovina spamu pryč. Ta druhá je v příchozí poště. Navíc já chci ty vzkazy uchovávat jen dočasně tak max 3 měsíce, takže nějaký spam mě nemůže rozhodit :) |
||
| Tomášeek Profil |
#23 · Zasláno: 8. 10. 2019, 00:38:25
Gray blogger:
„To nebylo lokálně, ale na wz.“ Ale bez uživatelů. „takže pokud zjistím, že dotyčný odesílal spamy, jednoduše smažu jeden soubor a tím pádem je polovina spamu pryč.“ ... čili to budeš denně všechno kontrolovat? Jak poznáš spam? Přečteš si zprávy uživatelů a posoudíš, jestli to je spam? „Navíc já chci ty vzkazy uchovávat jen dočasně tak max 3 měsíce“ Něco budu mít ve schránce a 3 měsících se mi to smaže? Jak technicky uděláš, pokud si budu chtít vyfiltrovat zprávy jen daného uživatele? Navíc za obdoví „3. sprna až 10. září“? Asi to vzdávám. Ty seš přesvědčen o tom, že tvůj postup je správný, tak fakt jen good luck. Trochu mi to připomíná to přísloví, neber to osobně, „Blbec neuvěří nikdy tomu, že je blbec... protože je blbec.“ Ale třeba zjistíš, že šlapeš slepou uličku a bude tě to stát měsíc zbytečné práce nyní, zbytečnou práci s učením se práce se soubory a nakonec skončíš u databází. |
||
| Keeehi Profil |
#24 · Zasláno: 8. 10. 2019, 02:17:36
Gray blogger:
„Milion? To se nikdy nemůže stát.“ Jak myslíš, že dlouho bude útočníkovi trvat zápis milionu záznamů. Řekl bych že tak pár minut. To budeš ten web co chvíli kontrolovat zda ti to ještě funguje? Nicméně, odpověďmi sem jsem strávil přibližně tolik času jako mi zabralo se jako začátečníkovi naučit zaklady SQL. Tudíž jsi vyčerpal zásobu minut kterou mám vyhrazenou na lidi, kteří vlastně poradit ani nechtějí, protože to správné řešení znají přece jen oni. Sice moc nechápu, proč se v tom případě vůbec na něco ptají ale co už. Kdybys náhodou někdy prozřel, tak dej vědět. |
||
| Gray blogger Profil * |
Tomášeek:
spam přece hlásí uživatelé, když jim něco přijde jako spam. Přece nebude spammer odesílat spam sám sobě :-) Tomášeek: Zálohování zpráv. Filtrování tam nebude. Přehled ano. Ale ujasněme si, že se bavíme v rovině teoretické. Zatím se do projektu vzkazník nepouštím, nemám na to teď čas a nevím kdy ho budu mít. Zatím je to jen o registraci a přihlašování. Znám také různá zajimavá přísloví, která bych mohl použít na tebe, ale nechci to dělat. Keeehi: Existují antispamové ochrany. Kdyby to tak bylo taj snadné, tak by nikdo neprovozoval, protože by každou chvíli všichni měli přetížený weby. |
||
| Tomášeek Profil |
#26 · Zasláno: 8. 10. 2019, 09:58:14
Gray blogger:
“Znám také různá zajimavá přísloví, která bych mohl použít na tebe” Zkus, je-li to k tématu. Rad se něco o sobě dozvím. :-) Jinak Keeehi už asi řekl vše podstatne v #24. Milion spamu tam muže být za minutu, já bych docela rad viděl kousek kódu starající se o login, resp. registraci, ale ten asi neukazes, co? Podělís se aspoň o způsob ukládání a zabezpečení hesel? |
||
| Gray blogger Profil * |
#27 · Zasláno: 8. 10. 2019, 12:34:07
Tomášeek:
Ne podělím se vůbec o nic, ani o přísloví to si nechám pro sebe. To bude nejmoudřejší. |
||
| Tomášeek Profil |
#28 · Zasláno: 8. 10. 2019, 12:40:27
Gray blogger:
Ty máš dost borče... :-) No nic, good luck. A upřímně doufám, že uživatel té tvojí aplikace budeš max. sám. Kvůli bezpečnosti ostatních. |
||
| Anonymouz Profil |
#29 · Zasláno: 8. 10. 2019, 15:44:15
Gray blogger:
Taky se mi nechce učit MySQL, ukázal by jsi mi tu tvoji aplikaci? Nad něčím podobným jsem laboroval pár let nazpět. |
||
| Gray blogger Profil * |
#30 · Zasláno: 8. 10. 2019, 17:05:50
Není možné z bezpečnostních důvodů nebudu svoje skripty nikomu nabízet. Tím bych potenciálním hackerům jenom usnadnil práci. Mohl bych jen dát nějaké tipy.
Třeba parsování souboru se dá výrazně urychlit tím, že si do každého záznamu ukládáš délku řetězce (řádku). Pokud chceš ušetřit místo, tak můžeš decimální čísla převést (zakídivat) na string. Je to něco spodobného jako je funkce intval, jenže místo s desítkami pracuju s číslem 223 a to číslo posunu o 32 bajtů (rozsah je 0..223; 223 je to samé co v desítkové soustavě 0; dělíš zprava doleva a používáš zbytek jako při normálním matematickém dělení). Vyhýbám se objektovému programování, které je výrazně pomalejší na výkon (zavádění instancí je pomalé i v jiných jazycích a u PHP je to znát). Vyhýbám se rekurzivním funkcím, které jsou pomalejší než cyklus for. Používám hlavně requirování ze souborů. Jsou to krátké skripty a myslím, že každý si takovou věc zvládne napsat sám. Není to nic těžkého. Návrh vzkazníku: Jeden uživatel by měl mít asi 7 souborů. 1 Soubor s obecným nastavením, kde se zobrazí i nové zprávy. 1 soubor příchozích zpráv, 2 soubor odchozích zpráv, 1 soubor s rejstříky příchozích zpráv a 1 soubor s rejstříky odchozích zpráv - tyto mají odkazovat na offsety v txt souboru, kde má uživatel záznamy. Ještě není jisté jestli tyto dva jsou třeba, protože když si do řádku uložíš číslo následujícího záznamu toho uživatele kterého načítáš, bylo by možné provádět parsování velmi rychle - ale s jednou nevýhodou - potřeboval bys rezervovat 4-5 bajtů pro uložení délky řetězce - protože nevíš jak velký bude offset až další uživatel vloží záznam (pošle zprávu). Počítám s tím, že zprávy by se občas měly promazávat, ale to fakticky znamená udělat export.... Jinak je nutné zprávy ve starém souboru fakticky nemazat, jen deaktivovat, aby nebyly vidět ve vzkazníku a při listování je pak ignorovat. Aplikaci, kterou budu psát je pro specifický projekt nebo pro specifickou úzkou skupinu lidí, takže neočekávám že by v jednom čase bylo přihlášeno třeba 50 uživatelů, ale jen pár. |
||
|
Téma pokračuje na další straně.
|
|||
0