Příspěvky

736

Sítě / Re:DMZ s veřejnými adresami vs DMZ s privátními staticky NATovanými adresami

« kdy: 03. 02. 2022, 16:26:13 »

Jak píšou ostatní, NAT je obezlička pro případ, když nemáte jinou možnost. NAT vám nikdy nepřinese nějakou přidanou hodnotu, může něco akorát rozbít. Takže když nemusíte NAT použít a máte veřejné IP adresy, použijte je.

737

Windows a jiné systémy / Re:Prohlížeče ignorují soubor hosts na Win 10 Home

« kdy: 03. 02. 2022, 12:20:27 »

Nějak mi uniká smysl spekulací o tom, co by to mohlo být, když už je to dávno vyřešené.

usergone si pro svůj lokální vývoj zvolil nějakou doménu s koncovkou .dev, aniž by věděl, že existuje TLD .dev, nebo aniž by si uvědomil, že není dobrý nápad používat doménu, kterou nevlastním. No a na doméně .dev je pomocí HSTS preload pro všechny povinné HTTPS, což je informace, která je mezi webovými vývojáři všeobecně známá. usergone o tom ovšem nevěděl a mylně si vyložil to, že prohlížeč nezobrazil požadovanou webovou stránku, tak, že prohlížeč ignoruje soubor /etc/hosts. Přitom stačilo otevřít si DevTools a tam by viděl, že se prohlížeč pokouší připojit protokolem HTTPS, ovšem spojení se nenaváže, protože server na portu 443 nenaslouchá.

No, a za to všechno samozřejmě může Google – za to, že měl usergone nápad vymyslet si doménu pod existující TLD .dev, že nevěděl o tom, že je ta doména v HSTS preload listu a že to, že prohlížeč nezobrazí požadovanou webovou stránku, řeší aniž by otevřel DevTools. Protože Google je vlastníkem .dev, Google spravuje HSTS preload list a Google je autorem Chrome – takže kdo jiný by za to mohl, že?

738

Windows a jiné systémy / Re:Lokalny vyvoj s HTTPS - win

« kdy: 02. 02. 2022, 21:01:08 »

To bude potřeba napsat, co vlastně chcete vyvíjet. Klienta, server, webovou aplikaci, RESTové služby, něco jiného? Spousta nástrojů má už podporu pro HTTPS vestavěnou.

739

Windows a jiné systémy / Re:Prehliadace ignoruju hosts file na Win 10 Home

« kdy: 02. 02. 2022, 18:37:48 »

Obávám se, že za to, že si vymýšlíte vlastní doménu v existující TLD, Google fakt nemůže. Ani za to, že jste do dotazu neuvedl skutečnou doménu, kterou používáte. Protože s doménou .bar nemá Google nic společného.

740

Windows a jiné systémy / Re:Prehliadace ignoruju hosts file na Win 10 Home

« kdy: 02. 02. 2022, 17:06:06 »

Nemáte v prohlížeči/systému nastavený nějaký proxy server? Třeba nějaký antivir?

Předpokládám, že jste upravoval soubor C:\Windows\System32\drivers\etc\hosts.

741

Server / Re:System hostname vs Posftix myhostname

« kdy: 02. 02. 2022, 08:46:09 »

V Postfixu můžete mít libovolné jméno, nezávisí to na jménu systému. Je vhodné, když je to jméno, na které vede reverzní DNS záznam (PTR) IP adresy, která se posílá k posílání e-mailů, a k tomuto jménu by zase měl existovat A/AAAA záznam, který povede na danou IP adresu.

To „hostname is not valid“ je divná hláška, chtělo by to vidět jí v kontextu. Jestli se opravdu týká myhostname a jestli v tom myhostname nebylo něco jiného, třeba jestli tam nebyl zapomenutý nějaký znak navíc (tečka, mezera).

742

Vývoj / Re:Je „responsivní“ design až zase tak potřebný?

« kdy: 26. 01. 2022, 16:19:57 »

Správně udělaný responzivní design je rozhodně přínosem. Špatně udělaný web znamená akorát jeden špatně udělaný web, neplyne z toho, že musí být špatně udělané všechny weby.

No a pokud vám web nějakého e-shopu nevyhovuje, tak na něm prostě nenakupujte. Jiné řešení to nemá.

743

Server / Re:Přístupová práva k souborům pro podřízeného uživatele

« kdy: 26. 01. 2022, 16:06:16 »

Na linuxu pro jednu úroveň tohle řeší sgid bit na adresáři – zařídí, že vlastnická skupina nově vytvořených souborů a adresářů bude shodná se skupinou adresáře, nikoli primární skupinou uživatele. Takže by existovala třeba skupina www-pepa, ve které by byl uživatel pepa i www-data. Tahle skupina by vlastnila adresář ~pepa/www. Na adresáři, kam má mít www-data právo zapisovat (třeba ~pepa/www/upload), pak bude nastaven sgid bit (a bude ho vlastnit také www-pepa), takže soubory v něm vytvořené bude také vlastnit skupina www-pepa. Nicméně nic nebrání uživateli www-data tu skupinu dodatečně změnit na nějakou jinou.

Na druhou stranu, pokud nemá adresář nastaven sticky bit, mazání souborů se neřídí právy souboru, ale právy nadřazeného adresáře – protože smazání souboru ve skutečnosti znamená „smazání záznamu o souboru v obsahu adresáře“. Takže neplatí vaše věta, že by uživatel pepa ztratil moc nad vytvořenými soubory v adresáři upload – bez sgid bitu by pepa sice třeba nemohl číst soubory v adresáři upload, ale smazat by je mohl. (Řeč je teď o situaci bez sgid bitu, nebo když uživatel www-data dodatečně skupinu změní.)

Komplikovanější to bude, pokud v tom adresáři upload bude webová aplikace vytvářet i podadresáře. Protože pak by bylo potřeba, aby i těmto podadresářům nastavovala sgid bit.

Unixová práva jsou neintuitivní a obvykle jakmile někde může jiný uživatel vytvářet adresáře, ztrácíte nad tou adresářovou strukturou kontrolu – máte totiž v ruce jenom defaulty, které může jiný uživatel ignorovat a které se často ani nepropisují automaticky do podřízených složek. Něco se dá obejít pomocí ACL, ale i tak je spoustu neřešitelných situací. Obecně unixová práva fungují tak, že brání, aby se uživatel nedostal k souborům, ke kterým přístup mít nemá. Nedokáží ale obecně zabránit tomu, aby uživatel sebral přístup někomu jinému k něčemu, k čemu přístup mít má. Což má svou logiku – když uživatel může ten soubor přepsat nulami nebo zkrátit na nulovou délku, jeho obsah může znehodnotit tak jako tak. Takže nedává smysl bránit mu ve znehodnocení souboru tím, že k němu odebere práva ostatním. Nicméně reálně ten případ, kdy odeberu práva ostatním, nastává v drtivé většině případů nechtěně, kdy prostě při vytváření nebo kopírování souboru či adresáře zůstanou práva nastavená nějak a nikdo neřeší, že by měl po té ještě správně nastavit práva.

Podle mého názoru jsou mnohem silnější hierarchická práva, jaká má třeba NTFS nebo je měl Novell. Na druhou stranu jsou náročnější na implementaci, zejména v prostředí, kdy můžete jeden adresář připojit kam je libo.

744

Server / Re:Postfix - jak nakonfigurovat chování adresy příjemce jako má GMail

« kdy: 26. 01. 2022, 08:57:53 »

Doména v regulárním výrazu nemusí být uvedená. Prostě tam dejte, že za zavináčem může být cokoli, zapamatujte to jako skupinu a tu pak vložíte zase do pravé části za zavináčem – v tom vámi uváděném příkladu už to podobně je udělané.

745

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 12. 01. 2022, 16:15:18 »

A teraz by to chcelo zrovnat branky, bud by ste mal pouzit kod ktory ste sem postoval, alebo ja ten svoj optimalizujem.

Vy jste tvrdil, že je pomalé volat pro každé nahrazení funkci. To je kód, který je v tom testu. Já jsem v mém původním návrhu měl feturu navíc, že bylo možné každý token nahrazovat jinou náhradou, takže se tam volala další funkce. Nic takového váš kód nedělá, takže jsem srovnal podmínky tak, aby oba kódy dělaly to samé.

Naviac ked ten kod prebehne 1000000 krat tak jit s optimalizatorom bezpecne zafunguje. Preco by ale niekto ten isty text nahradzoval 1000000x dookola?

To jsou zase jen vaše dohady. Které se neukázaly jako moc dobré. Ak byste někdy dělal výkonnostní testy aplikace, věděl byste, že se kód často volá opakovaně, aby se výkon vůbec dal nějak změřit. Proč by někdo ten stejný text nahrazoval 1 000 000 × dokola byste měl odpovědět vy, protože vy jste přišel s tím, že je potřeba to optimalizovat na čas. Pokud se ten text bude nahrazovat jenom jednou a trvá to po jednu milisekundu, proč to optimalizovat?

Ale že jste to vy, dal jsem tam přesnější čítač času, takže teď už to můžete pustit i jenom jednou. Akorát že zjistíte, že to už se pohybujeme v oblasti chyby měření a jediné, co se dá říct, je to, že výkon těch funkcí je zhruba stejný. Což je opět v rozporu s vaší tvrzením, že můj kód je neefektivní.

Njn, ako som si myslel.

Njn, jenže to už testujete něco jiného, protože jste kus vaší funkce vytrhl mimo test, takže neměříte dobu trvání celé vaší funkce. Pak je to opravdu optimalizace na velký počet nahrazování se stejnou sadou tokenů (což je zase váš nevyslovený předpoklad, že něco takového bude potřeba), tedy je to jiné zadání. Jinak v tomhle speciálním případu (o kterém ale původně nebyla řeč) je vaše funkce opravdu cca o 1/3 rychlejší. Láme se to teprve u dost vysokého počtu tokenů – u deseti tisíc tokenů už je výrazně efektivnější hledání tokenů v hashmapě než jejich procházení po jednom v regulárním výrazu.

Ale to je len tym ze sa ten kod zopakuje milion krat a tym ste si zarucil ze sa to zkompiluje.

To vaše vytváření regulárního výrazu se zaručeně nezkompiluje ani při milionu provedení?

746

Server / Re:Odchozí pošta padá do spamu ; guessSPF ; ? shoda From,MAIL FROM , HELO

« kdy: 12. 01. 2022, 12:10:01 »

1.V hlavičce (v webovém rozhraní zkoušeno jen) jsou jen hlavičky od odesilatele a POUZE "RECEIVED: from+by". Žádné Authentication results, spam-score... (Vím že může prezentovat uživateli e-mail v originální příchozí formě, BFU by tomu stejně nerozuměli)

Výsledky antispamové kontroly ení nutné zapisovat do původního e-mailu. Klidně mohou být zapsané někde v databázi, nebo se prostě předají aplikaci doručující do schránek jiným způsobem. To, že se ty hlavičky přidávjaí do e-mailu, je spíš obezlička, když se spamové filtry do zpracování filtrů zařazovaly dodatečně a nebyl jiný (a univerzální) způsob, jak hodnocení z antispamu „propašovat“ dál v řetězci zpracování ke službě, která ukládá e-maily do schránky, případně je má zahodit nebo přesunout do složky se spamem.

Rozhodně se z toho, že v e-mailu nevidíte přidané hlavičky antispamu, nedá soudit, že by server kontrolu neprováděl. A třeba kontrola IP adresy a domény se často provádí už v rámci SMTP relace – když kontrola neprojde, je e-mail rovnou odmítnut. Když projde, tak je z tohoto pohledu v pořádku a není důvod o tom dělat nějaký záznam.

- From a MAIL FROM se liší. Jako vím, že to je jasný příklad  "outsourcingu posílání mailů/remailingu. Nic proti tomu nemám.  Ale zaprvé proč (2) mě na to neupozorní Desktopový klient

Protože to MAIL FROM je čistě transportní záležitost serverů. Jako by vás Pošta upozorňovala, že balík nepřivezli přes Brno ale přes Ostravu.

JE snad někde dané, že HELO a doménová část MAIL FROM se mají rovnat?

V žádném případě. To, že se liší, je běžná věc – pokud bych si měl tipnout, řekl bych, že se doručí víc e-mailů, kde se tohle liší, než kde je to stejné. Vlastně správně by to ani stejné být nemělo – v EHLO má být jméno zařízení, v MAIL FROM doména.

747

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 12. 01. 2022, 08:47:48 »

https://codepen.io/filipjirsak/pen/RwLqNJg

No neke, tak si to skuste opravit funcA a funcC aby ich vystup nevratil to iste ako je input. FuncB nieco skutocne nahradzuje a je daleko pomalsia koli tomu ze robi to co sa pozadovalo - nahradzuje najdene retazce. Mozno to na 2 pokus date

Dobře, speciálně pro vás jsem na konec přidal ještě porovnání výstupů. Ak byste tomu kódu nerozuměl, tak jsem tam přidal i výpis vstupu a výstupu, můžete si to porovnat očima.

Tak co, už můžeme zveřejnit výsledky, že ten váš kód je cca 3× pomalejší?

Každopádně vám děkuji za názorný příklad toho, proč je předčasná optimalizace špatně. Pustil jste se do optimalizace něčeho, o čem jste vůbec nevěděl, zda je to pomalé. A při optimalizaci jste ve skutečnosti vyrobil třikrát pomalejší kód. Asi jste se (mylně) domníval, že regulární výrazy jsou jakási magie, jejíž složitost můžete zanedbat. Ak byste tušil, jak regulární výrazy fungují, napadlo by vás, že jste tím vaším kódem pravděpodobně vyrobil tu vnitřní smyčku, kterou jste vytýkal mému kódu (a která v mém kódu není).

Zkuste si z toho zapamatovat alespoň to, že svislítko | v regulárních výrazech je vždy nebezpečné, pokud vám jde o výkon. A na vašem místě bych také přehodnotil přístup, že nemusíte měřit rychlost kódu, protože máte představu, co je asi jak rychlé. Evidentně jsou vaši představy o fungování kódu mylné.

748

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 11. 01. 2022, 19:44:45 »

Ale rozhodie nie tak ze to vsetko strcite do jednej funkcie/metody.

Někdo snad tvridl opak?

Kometarmi zbavit kod spagiet... To by chcelo zapis na wikicitaty

To jste ovšem teď napsal vy. Já jsem nic takového nenapsal.

Tak co myslite, co bude efektivnejsie. Funkcia F napisana v C(alebo v ruste v pripade spidermonkey) ktoru zavolam s predpipravenym parametrom, alebo kod ktory sa mozno interpretuje, mozno prelozi a potom zavola a napokon bude volat funkciu F? Fakt si to potrebujete zmerat?

Za prvé, prohlédněte si znovu a lépe kód, který jsem napsal. Porovnáváte volání funkce F s jendím parametrem s voláním funkce F s jiným parametrem.

Za druhé, nikde není řečeno, že interpretovaný kód musí volat funkci F. Výhoda JIT je, že optimalizuje kód na míru aktuálnímu běhu programu. Takže ten kód může být mnohem efektivnější, než obecná optimalizace vznikající v okamžiku jednorázového překladu aplikaci. Efektivnější může být například i tím, že nebude volat obecnou funkci F, ale zavolá mnohem rychlejší specializovanější funkci F'. Tohle byste ovšem měl vědět, když se tu prezentujete jako odborník na JIT kompilaci.

Je rozdiel medzi poucovanim, a domienkou. Preto som zacal s "ak". Naproti tomu vy ani nepoucujete, vy rovno kadrujete "Navíc jenom hádáte, jak by asi tak mohl interpret JavaScriptu fungovat."

Aha, no dobře, bude všechny své domněnky pro vás uvozovat „ak“.

Ad normalna diskusia: Nemam ten dojem ze by to tu bolo preplnene ludmi s ktorymi najdete spolocnu rec. Skor na opak. Ste si naozaj isty ze problem nie je vo vas ale v masach?

O věcech, o kterých si myslím, že masy vědí stejně nebo lépe než já, nepíšu. O takových věcech si čtu, případně se ptám. Ak vy píšete o věcech, o kterých toho masy vědí víc, než vy, leccos by to vysvětlovalo. Akorát bych řekl, že v takovém případě by bylo lepší, kdybyste nic nepsal.

To ze som v suchu

No jo, jenže vy nejste v suchu. Vy jenom tvrdíte, že se rozhodně nebudete dívat na své kalhoty, protože fouká severní vítr.

749

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 11. 01. 2022, 19:04:30 »

Tak ako som to napisal ja, to nemusi byt nutne spolu, moze to byt v predkovi z inej kniznice.

Objektové programování je jeden ze způsobů, jak udržovat pohromadě kód, který k sobě patří (předci třídy).

Magicke funkcie ktore zahrnaju viacero funkcnosti v jednom, je skolsky priklad spagetaku.

Ano. Ale nebylo by nijak pracné váš kód zbavit špaget – což jste viděl sám a umístil jste komentáře tam, kde by mohla být funkce.

V tom ze sa automaticky spusti jit kompilator.

Mýlíte se. To, jestli se spustí či nespustí JIT kompilátor nedokáže autor JavaScriptového kódu přímočaře ovlivnit. Pokud nevíte, co znamená termín „předčasná optimalizace“ – znamená to, že autor kódu napíše kód jinak, než by ho psal normálně, v domnění, že takový kód bude efektivnější.

Ak by ste mal aspom tusenie ako funguje V8

Ja nepoucujem ale pisem svoj nazor, na zaklade svojich skusenosti. Ak nemate dispozicie viest dialog, ale vydupavat si to ze ako jediny mate pravdu, tak pravidelna navsteva diskuzneho fora musi byt pre vas velkym utrpenim. Sucitim s vami.

Aha, takže ta první citace není poučování.

Já normálně diskutuju, nevydupávám si, že jako jediný mám pravdu. Ale nevím, proč bych nemohl upozornit na to, když někdo napíše něco špatně. Pokud se vás takové upozornění dotýká, je to váš problém, ne můj.

Ak ja curam po vetre a vy proti vetru, tak to neznamena ze to robite lepsie nez ja. I ked ja curam, vy curate. K poznaniu ze curanie proti vetru nie je dobry napad, nemusim nutne skusit vas sposob.

Zkoušet to samozřejmě nemusíte. Problém je, když vítr fouká opačným směrem, než si myslíte.

750

Server / Re:Gmail zahazuje maily?

« kdy: 11. 01. 2022, 18:53:06 »

Proc ale penalizovat zip (bez hesla, proskenovatelnou na serveru antivirakem) prilohu? Pokud plati ze spammeri pouzivaji botnety z ruznych domacich routeru a pod, pak by jim posilani 10M prilohy (navic MIME to podstatne zvetsi) jen komplikovalo rozesilani, ucpavalo TX na asymeterickych linkach, a obecne neprinaselo zadny uzitek.....

Přílohy mají pro spammery ten užitek, že do nich často antispam nebo ani antivir nedosáhne. Před nějakou dobou byl docela oblíbený spam, kdy obsah e-mailu byl prázdný a byl přiložený jediný obrázek nebo PDF soubor. Antispam vyhodnotil obsah, nenašel tam nic závadného (bodejť by ne, když tam nebylo nic) a e-mail bez ztráty květinky prošel.