Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: [1] 2 3 ... 273
1
Software / Re:Sdílený adresář
« kdy: Dnes v 15:14:02 »
ACL by to nevyřešilo?
Stačí si přečíst předchozí komentáře…

2
Ahoj,
asi bych to měl lépe specifikovat. Jde mi o spolehlivost vůči ztrátě dat a ne o 24/7 dostupnost. Ta je mi ukradená. Je to do malé firmy. Když nastane závada na NASu tak to se stát může, ale nesmí to odnést data.
Pořád platí 1. odpověď – RAID 1.

Spolehlivost samozřejmě razantně zvýšíte tím, že nenacpete všechny ty disky do jednoho NASu. Největší spolehlivosti samozřejmě dosáhnete tím, že těch 8 disků dáte na 8 různých míst.

Vy ale pravděpodobně nechcete jen spolehlivost. Nejspíš chcete nějaký kompromis mezi spolehlivostí, kapacitou a cenou. Jenže my nemůžeme vědět, jaký kompromis chcete. Jeden extrém je 8 disků na 8 různých místech, celková kapacita rovná kapacitě jednoho disku. Druhý extrém je 8 disků v 1 NAS serveru, buď jako JBOD nebo dokonce jako RAID 0. Kapacita je pak rovná součtu kapacit všech disků, ale pokud nějaký disk odejde, určitě přijdete o data (pokud ten disk nebude prázdný).

Mnohem větší spolehlivosti dosáhnete zálohováním. RAID neřeší spolehlivost, nýbrž dostupnost.

3
Software / Re:Sdílený adresář
« kdy: 21. 01. 2021, 19:43:10 »
To tedy nestačí. Tazatel chce, aby v tom adresáři mohl kdokoliv dělat cokoliv a to i když tam někdo přesune soubor. Když do toho "vašeho" adresáře přesunu soubor s právy 0600, tak další uživatel ho může leda smazat, ale nepřečte ho.
Máte pravdu. Já jsem se soustředil jen na to mazání (jak je ostatně z mého komentáře zřejmé), myslel jsem, že je problém v tom.

Laskavě nám nevysvětlujte, že si má uživatel hlídat práva nebo nastavit umask jako s tím, v tomto případě irelevantním, sticky bitem.
A vy si laskavě odpusťte tohle vysvětlování na základě nesmyslných předpokladů.

Bohužel ani tohle nestačí, při přesunu se default ACL nenastavují.
Přesouvání bude vždycky problém. Samozřejmě je to věcí aplikace, zda při přesunu nedělá nějaké další operace, ale samotné přesunutí prostě soubor opravdu jen přesune, práva nijak nemění. A v unixových souborových systémech se práva nedědí, má je vždy ten konkrétní soubor.

Jediné opravdu funkční řešení nezávislé na použitém nástroji pro kopírování/přesun, na zdrojových právech nebo filesystému je hlídat cílový adresář nějakým softwarem přes inotify a nastavovat si požadovaná práva. Na "prasáka" to jde periodicky měnit i  skriptem v cronu.
Souhlasím. Především to přesouvání bude vždy problém.

4
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 17:56:09 »
Je mozny, ze vymyslis kolo. Zkus si neco precist o SAML, Federation Services, OpenID.
Pokud nechce řešit přihlašování heslem jako příliš složité, pochybuju, že chce řešit SAML nebo federation services.

PS: jeste dost zalezi na tom jestli to pobezi na Internetu anebo na korporatnim intranetu.
Poběží to na internetu, jak je zřejmé z dotazu.

5
Software / Re:Sdílený adresář
« kdy: 21. 01. 2021, 17:13:14 »
Pro smazání souboru potřebujete jen práva -wx na nadřazeném adresáři. Práva daného souboru se vůbec neberou v úvahu. Naopak je potřeba speciální nastavení adresáře (sticky bit), které třeba v /tmp brání uživatelům smazat soubory jiných uživatelů.

Takže k tomu, co popisujete, stačí na /home/sdilene nastavit práva rwx pro všechny (nebo pro skupinu, které se to týká), a nenastavovat tam nic jiného speciálního.

6
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 17:07:29 »

Nene, naštěstí jste se vrátil do zajetých kolejí a opět se pletete  ;D

Co takový index.php nebo router.php může dělat:
- routovat požadavek
- provádět include
- posílat dotaz do databáze, jestli daný klíč vůbec existuje
- logovat každou z jednotlivých položek

Pokud tam implementuji jednoduchou paritu (která nebude zjevná), mohu požadavek zahodit dřív, než se začnu připojovat do databáze a dělat ostatní kraviny.
Pro začátek vynecháme věci, které s ověřením klíče nijak nesouvisí. Takže pokud bude klíč náhodně generovaný řetězec, bude ověření klíče znamenat najít ho v seznamu vydaných klíčů. Vzhledem k tomu, že podle dotazu předpokládám tak desítky nebo stovky uživatelů, celá „databáze“ klíčů se vejde do paměti jako vyhledávací strom nebo hash tabulka.

Pokud by klíč bylo JWT, znamená to dekódovat reperezentaci klíče, ověřit podpis (předpokládejme rychlejší variantu s hashem). Pokud bude podpis platný, dekódujeme data z JWT, získáme identifikátor – a ten už můžeme hledat v databázi klíčů jako v předcházejícím případě. Pro oprávněného uživatele je to mnohem delší cesta, pro někoho, kdo jen zkouší náhodné klíče, to s tím dekódováním a hashováním nejspíš bude také delší, než jednoduché vyhledávání.

Pokud by tam nebylo JWT, ale „jednoduchá parita, která nebude zjevná“, je to učebnicový příklad security through obscurity.

Ale hlavně, pokud někdo na prostor klíčů třeba 2256 zkouší útočit hrubou silou, buď protože si neodhadl, jak velký ten prostor může být, nebo protože tomu nerozumí – pak je to nějaké tele, které bude možné jednoduše eliminovat blokací jedné IP adresy na firewallu.

7
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 13:48:59 »
Citace
Rozhodně nespoléhat na náhodný řetězec, minimálně by to chtělo zapojit J(son)W(eb)T(okens)
Mám náladu na komickou vložku. Takže se zeptám – proč?
Bude z toho poznat, že jde o neoprávněný pokus, jestliže pujde o random string.
To máte pravdu, jenže je otázka, zda zrovna tohle by bylo úzké hradlo aplikace. Dávalo by to smysl u nějaké aplikace typu CDN, kde by hraniční servery rovnou dokázaly eliminovat zjevně neplatné pokusy a vůbec je nepouštět dál. U takovéhle aplikace, která poběží na jednom serveru a bude mít pár platných klíčů, se tím podle mne moc výkonu neušetří. Naopak to zavádí složitost do vývoje.

8
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 12:59:20 »
Použití dlouhých klíčů skutečně dostatečně naředí celý prostor (což jsem i zmínil), navíc nám pomůže webserver, který není příliš rychlý a při nastavení vhodných pravidel proti útokům (DOS/DDOS) se to stane neefektivní.
Ten klíč musí být tak dlouhý, že to bude neefektivní i bez omezení proti DoS/DDoS útokům, i bez spoléhání na pomalost webserveru. Navrhněte to tak, aby to bylo neefektivní, i kdyby se útočník přímo na svém zařízení jedinou instrukcí procesoru dozvěděl, zda klíč existuje nebo neexistuje. A pak k tomu přidejte ještě několik řádů. Povolená délka URL je pro tohle opravdu dostatečná a přidat ke klíči pět deset bajtů navíc nikomu nic neudělá, ale vás to zbaví nutnosti nad tím přemýšlet.

9
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 11:12:37 »
Je nutné myslet na bezpečné předání a uchování URL.
Autor na to může myslet jak chce, ale ničemu to nepomůže – předávání ani uchování URL nemá pod kontrolou.

Samozřejmě to chce nějakou logiku kontroly přístupu, aby nebylo možné hádat 32000 přístupů za vteřinu.
Právě naopak, tady by byla výhoda, že klíč může být dostatečně dlouhý, nebo-li prostor pro hádání natolik řídký, že nikomu nepomůže, i kdyby uměl zkoušet miliardu klíčů za vteřinu.

Rozhodně nespoléhat na náhodný řetězec, minimálně by to chtělo zapojit J(son)W(eb)T(okens)
Mám náladu na komickou vložku. Takže se zeptám – proč?

10
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 09:04:29 »
Děkuji, to jsou užitečné informace. Ještě to zvážím. Budu tam mít i klasickou autentizaci pro sebe jako admina, ale její zprovoznění pro všechny je spousta kódu navíc - zapomenutá hesla, požadavky na smazání účtu...
Smazání účtu musíte řešit stejně. Místo zapomenutého hesla byste musel řešit zapomenuté URL. Musel byste řešit i změnu přihlašovacího URL, stejně jako změnu hesla. Myslím, že použití externího poskytovatele identity, bez možnosti vytvořit účet se jménem a heslem, je pořád menší zlo, než takhle nestandardní přihlašování. V MojeID si základní účet může vytvořit každý. Když použijete OpenID, tam si každý může provozovat vlastní server – kdyby měl někdo touhu opravdu nebýt závislý na žádném třetím poskytovateli.

Nebo použijte už hotové řešení, třeba Firebase Authentication. Jsou v tom jména a hesla, přihlašování přes Google, Facebook, Twitter, Apple, Microsoft, GitHub… Pokud nebudete chtít ověření přes telefon, máte to zdarma. To mi pro vás připadá jako nejlepší řešení.

11
Vývoj / Re:Přihlašování pomocí URL
« kdy: 20. 01. 2021, 21:18:42 »
Na to by se mohla hodit HTTP autentizace. Stačí, když se uživatel jednou přihlásí.
To záleží na tom, zda a jak si prohlížeč zapamatovává hesla. A v jiném prohlížeči (na jiném počítači) se bude muset přihlašovat znovu. To už může použít nejpoužívanější autentizaci přes formulář, kde budou aspoň fungovat i správci hesel implementovaní jako rozšíření prohlížeče (ti na dialog HTTP autentizace nedosáhnou).

12
Vývoj / Re:Přihlašování pomocí URL
« kdy: 20. 01. 2021, 19:50:21 »
Nevýhodu to má jednu dost podstatnou a docela zřejmou – URL není považováno za dlouhodobě tajný údaj, takže se nedá spoléhat na to, že někde neunikne. Zůstává v historii prohlížeče, v hlavičce Referer ji dostanou všechny objekty stahované ve stránce (externí obrázky, skripty apod.), všechny stránky, na které se uživatel z vaší stránky proklikne. Proto mívají takováhle autentizační URL omezenou časovou platnost.

Pokud opravdu chcete jít touhle cestou, doporučil bych alespoň ten přihlašovací token nedávat do serverové části URL, ale do fragmentu (za hash). Ten neopustí prohlížeč, není v Referer hlavičkách. Samozřejmě ho pak budete muset JavaScriptem přečíst a přidat do autentizační hlavičky, aby měl server podle čeho uživatele autentizovat.

Také určitě budete potřebovat možnost ten token zneplatnit v případě, kdy uživateli unikne.

Nicméně osobně bych ulehčení přihlášení řešil spíš tak, že uživatelům povolíte i autentizaci pomocí Facebooku, Google, Twiteru, MojeID, případně služeb, které jsou v daném oboru obvyklé. Váš způsob, že si uživatelé budou muset uložit adresu do oblíbených nebo jít pokaždé přes e-mail – vy tak možná web používáte, ale většina uživatelů asi ne.

13
Software / Re:Jak zablokovat anti-adblocker ochrany
« kdy: 14. 01. 2021, 14:57:31 »
Byl jsi požádán, abys nepřispíval. Pár tvých rad a názorů jsem už na rootu viděl a chci se tedy zeptat, lze nějak tohoto šaška, globálně zablokovat?
Je mi jasné, že kvůli naprosto dementním názorům, nelze někoho blokovat na serveru, ale kdyby existoval nějaký efektivní způsob, jak tohoto šaška bloknout na klienské straně, byl bych vděčný.
Bohužel, tady na fóru neexistuje způsob, jak uživatelsky blokovat uživatele. Kdyby existoval, vůbec bych neviděl tenhle dotaz.

14
Vývoj / Re:Extrakce informací z PDF faktur
« kdy: 14. 01. 2021, 08:33:35 »
Imho by do toho co s FA muzeme udelat maji co rict obe strany na fakture uvedene..
Pokud jedna ze stran vyžaduje zvláštní zacházení nad rámec zákona, musí to mít ošetřené už ve smlouvě.

15
Vývoj / Re:Extrakce informací z PDF faktur
« kdy: 13. 01. 2021, 21:26:55 »
Pan Jirsak zde patri k hardcore jadru, ale nema pravdu ve svem prispevku, faktura bude mit klasifikaci confidential (obsahuje ceny), takze by opravdu nemela opustit firmu bez explicitniho povoleni, jak bylo nastineno v jednom prispevku.
Vůbec mne nenapadlo, že by někdo začal používat na faktury nějaký systém jen tak na vlastní triko a neprojednal to s lidmi, kteří zodpovídají za to, jak se s fakturami nakládá.

Stran: [1] 2 3 ... 273