Příspěvky

241

Server / Re:FTP - kontrola uplnosti uploadu

« kdy: 20. 01. 2023, 18:45:12 »

Odpověď od Filipa Jirsáka jsem dostal a se spoustou bodů s ním souhlasím, ale pořád na FTP nevidím nic špatnýho, klidně bych ho doma používal jako způsob přenosu dat mezi PC a serverem. Až otevírání FTP do internetu by byla kravina.

Klidně doma FTP používejte :-) Já jenom nerad používám jiný protokol doma na domácí přenášení, další na přenášení mezi domovem a venkovním serverem a v dalších situacích třeba ještě jiný protokol, když jde stále o tutéž činnost – přenos souborů. Nechci přemýšlet nad tím, že teď sedím doma u svého notebooku a jsem připojen na domácí WiFi, takže můžu použít FTP, ale teď sedím doma u svého notebook a jsem připojen na WiFi hotspot vytvořený z mobilu, tak musím použít něco jiného, než FTP. Nevidím v tom žádnou výhodu. Nemluvě o tom, že bych musel na serveru udržovat další aplikaci.

242

Vývoj / Re:Regex dotaz

« kdy: 20. 01. 2023, 18:37:23 »

Pokud regexp engine, který používáte, podporuje vyhlížení, můžete nejprve zkontrolovat, že vstup nejsou jen číslice nebo jen písmena, a pak teprve použít vaši kontrolu. Pokud to nepodporuje, budete si to muset ošetřit přímo v aplikaci, tj. udělat ty testy za sebou dva nebo tři (podle toho, zda „jenom písmena“ a „jenom číslice“ otestujete v jednom nebo dvou krocích).

Dik, zkoušel jsem i toto, /^(?=.*?\d)(?=.*?[A-Z])[A-Z\d]+$/

ale dosud všechny moje pokusy skončily na tom {16}

No to {16} tam určitě musí být, aby to odpovídalo přesně 16 znakům.

Třeba tohle by mělo fungovat, tam kde se používá PCRE: ^(?![0-9]{16})(?![A-F]{16})[0-9A-Z]{16}$

dik moc
já nevím , to  by asi znamenalo 16cisel AND 16pismen AND 16znaku , ne ?
proc to ?! a ne ?=
som z toho volaaký zmätený

Ne, vyzkoušejte si to, třeba online na https://regex101.com Akceptuje to text, který je dlouhý právě 16 znaků a skládá se jen z číslic nebo velkých písmen, a zároveň to nejsou jenom číslice nebo jenom písmena (neboli musí tam být písmena i číslice).

(?!…) je tzv. negativní vyhlížení – tj. kurzor jakoby zůstane na místě, ale podívá se dopředu, zda je tam to, co odpovídá výrazu v závorce. U pozitivního vyhlížení by to bylo splněné tehdy, když tam takový text je, u negativního je podmínka splněná, když tam takový text není. Tj. (?![0-9]{16}) se podívá dopředu, zda tam není 16 číslic – když je, tak tahle část nevyhoví. Další skupina se podívá, zda tam není 16 písmen. Když je tam jen šestnáct písmen, tak výraz nevyhoví. A pak se teprve začne kurzor posouvat a 16krát porovná, zda je daný znak číslice nebo písmeno. Když ano, narazí na $, takže už jen zkontroluje, zda je na konci vstupu.

243

Vývoj / Re:Regex dotaz

« kdy: 20. 01. 2023, 17:11:35 »

Samozřejmě tam místo [A-F] má být [A-Z], nějak jsem se přepnul na představu, že tam mají být jen hexadecimální číslice

244

Vývoj / Re:Regex dotaz

« kdy: 20. 01. 2023, 16:52:16 »

Pokud regexp engine, který používáte, podporuje vyhlížení, můžete nejprve zkontrolovat, že vstup nejsou jen číslice nebo jen písmena, a pak teprve použít vaši kontrolu. Pokud to nepodporuje, budete si to muset ošetřit přímo v aplikaci, tj. udělat ty testy za sebou dva nebo tři (podle toho, zda „jenom písmena“ a „jenom číslice“ otestujete v jednom nebo dvou krocích).

Dik, zkoušel jsem i toto, /^(?=.*?\d)(?=.*?[A-Z])[A-Z\d]+$/

ale dosud všechny moje pokusy skončily na tom {16}

No to {16} tam určitě musí být, aby to odpovídalo přesně 16 znakům.

Třeba tohle by mělo fungovat, tam kde se používá PCRE: ^(?![0-9]{16})(?![A-F]{16})[0-9A-Z]{16}$

245

Vývoj / Re:Regex dotaz

« kdy: 20. 01. 2023, 15:26:53 »

Pokud regexp engine, který používáte, podporuje vyhlížení, můžete nejprve zkontrolovat, že vstup nejsou jen číslice nebo jen písmena, a pak teprve použít vaši kontrolu. Pokud to nepodporuje, budete si to muset ošetřit přímo v aplikaci, tj. udělat ty testy za sebou dva nebo tři (podle toho, zda „jenom písmena“ a „jenom číslice“ otestujete v jednom nebo dvou krocích).

246

Server / Re:FTP - kontrola úplnosti uploadu

« kdy: 20. 01. 2023, 09:30:54 »

Co jsem videl ruzna reseni, tak se ten soubor obvykle po uploadu prejmenovava, takze nejdrive ma treba priponu .tmp a pak teprve .xml apod. Nepotrebujete v tom pripade zadny dalsi adresar.

To má tu nevýhodu, že to musí dělat klient, který soubory nahrává. Výhoda je naopak v tom, že to udělá až po té, co bezpečně ví, že se tam soubor nahrál celý – tedy to řeší i případy přerušeného nahrávání, když se soubor nenahrál celý.

247

Server / Re:Automatický restart PostgreSQL

« kdy: 19. 01. 2023, 22:08:44 »

Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.

K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.

Bylo to myšleno tak, že pokud dojde k samovolnému pádu databáze (tj. není to tak, že by ji něco odstřelilo), bude nejčastější příčinou chyba někde mimo PostgreSQL, třeba chyba HW – chyba paměti nebo chyba disku. Pokud je chybná paměť nebo disk vrací nesmysly, je docela pravděpodobné, že už máte v DB poškozená data. Pokud tu DB bude provozovat dál, je dost pravděpodobné, že se ty chyby budou dál šířit (např. protože přes vadnou paměť půjdou další data). Nebo aspoň zálohy obsahující chybná data vytlačí zálohy, které tu chybu ještě neměly.

Tj. je nějaká společná příčina (vadný disk, vadná RAM) a způsobí dvě nezávislé věci – poškození dat a pád DB enginu. Pád DB enginu by měl být varováním před tou chybou a je riskantní po tom jen tak znovu spustit databázi, protože pokud ta chyba dokázala jednou něco pokazit, nejspíš bude škodit dál a vedle viditelných pádů DB může neviditelně poškozovat další a další data.

Jinak samotný restart by DB samozřejmě měla přežít bez úhony, je to prakticky stejné, jako když vypadne napájení. Ale jde o to, že DB servery obvykle samy od sebe bez vnější příčiny nepadají.

248

Sítě / Re:Výlučnost CNAME a MX: v jakém směru?

« kdy: 19. 01. 2023, 21:46:21 »

Přečtěte si RFC 1034, zejména sekci 3.6.2, a RFC 2181, zejména sekci 10.3. Nebo aspoň heslo o CNAME na anglické Wikipedii.

249

Server / Re:Má webhosting vliv na SEO?

« kdy: 19. 01. 2023, 18:40:44 »

Hosting může způsobit, že web bude pomalý, případně že občas/často nebude fungovat. To bude mít negativní dopady na SEO. Ovšem pokud budete používat WordPress (a nevytuníte ho tak, aby byl superrychlý), způsobí WordPress mnohem větší zpomalení, než způsobí nějaký pomalý webhosting.

250

Server / Re:FTP - kontrola uplnosti uploadu

« kdy: 19. 01. 2023, 16:10:54 »

Co je špatnýho na FTP? Když člověk přenáší nedůležitý data po LAN, ať už doma nebo ve firmě, tak je to snad jedno.

Za prvé, nedůležitá data nikam nepřenáším, rovnou je mažu. A u dat, která nejsou zjevně nedůležitá, odmítám přemýšlet o tom, zda jsou důležitá nebo nedůležitá a podle toho volit přenosový protokol.

FTP je nešifrovaný protokol, což se dá zalepit FTPS. FTP potřebuje pro přenos více portů a spojení navazované v obou směrech, což dělá problémy firewallům. Dá se to zalepit pasivním přenosem, ale i ten otevírá nové spojení na port, který není předem znám. Protokoly, kde se nejprve musí zalepit problémy, aby se vůbec daly začít používat, nemám rád.

Nejsou tam kontrolní součty ani kontrola přenosu, prakticky nemáte jak zjistit, pokud se soubor kvůli chybě nepřenese celý. Nedají se přenášet metadata souboru (kromě pár základních, se kterými počítá historický standard). Musí se řešit konce řádků, stačí drobná chybka a přenášený soubor poškodíte. Při přenosu můžete použít jen velmi slabou kompresi.

Místo FTP používám raději WebDAV, který je založený na HTTP, takže projde všude. Implementací HTTP klientů i HTTP serverů je všude spousta, takže i kdyby vám nevyhovovalo žádné z hotových řešení, není problém si něco upravit nebo si napsat vlastní (třeba posílat notifikaci v okamžiku nahrání souboru, ať nemusí druhá strana pořád zkoušet, zda už tam soubor není).

251

Server / Re:Automatický restart PostgreSQL

« kdy: 19. 01. 2023, 15:46:30 »

Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.

252

Server / Re:FTP - kontrola uplnosti uploadu

« kdy: 19. 01. 2023, 10:52:21 »

Tohle záleží na konkrétní implementaci FTP serveru. Ideální je, když uploadovaný soubor nahrává do dočasného adresáře mimo publikovanou strukturu a po dokončení uploadu soubor jen přesune do správného umístění. Přesun v rámci jednoho souborového systému je na Linuxu atomická operace, tj. nikdo přes FTP neuvidí částečně nahraný soubor – buď tam nebude vůbec, nebo už tam bude celý soubor.

Doufám, že aspoň používáte FTPS (šifrované FTP), když už používáte takovýto prehistorický protokol…

253

Vývoj / Re:Regulérní výraz pro funkce a metody v Go

« kdy: 18. 01. 2023, 20:44:36 »

tzn len naparuje tu zatvorku

Jednak pro regulární výrazy je problém už samotné vnořování párových závorek. Za druhé, to právě není pravda, že stačí napárovat závorky – jak už bylo řečeno, to vám rozbije závorka v textovém řetězci nebo v komentáři.

254

Vývoj / Re:Regulérní výraz pro funkce a metody v Go

« kdy: 18. 01. 2023, 19:14:45 »

Zdrojové kódy běžných programovacích jazyků (jako Go) se nedají zpracovávat regulárním výrazem. Jsou na to potřeba silnější výrazové možnosti (vyšší typ gramatiky).

255

Server / Re:Ochrana přístupu k webové aplikaci

« kdy: 16. 01. 2023, 16:41:57 »

(nejsem OP)

Pokud nejste Op ale Dev, Caddy se vám bude líbit, protože se dá krásně ovládat přes REST API :-)

díky za tip. Je to basicauth který je podobný třeba tý nginx implementaci, že na tebe browser vybafne modální?) dialog, nebo to má v sobě už nějakou trošku user-friendly stránku, kam jde cosi napsat?

Nejsem OP, ale s tohle potřebou jsem se už taky potkal, ale basicauth používá ten "ošklivý" dialog browseru, který některé password managery nepodporují, a ani to nevypadá moc důvěryhodně.. (mám rád, když je velice zřejmé, kam user zadává své kredence)

Takže třeba mě by se moc líbil "něco jako captive portal", který useru nastaví (třeba) nějakou správnou auth sušenku, a po přihlášení by ho nginx pustil dál.

Ano, BASIC auth je HTTP autentizace, tj. to samé, co odkazovali ostatní u Nginxu. Ano, bohužel jsou to ta ošklivá a divná modální okna v prohlížečích. Z hlediska implementace to má tu výhodu, že se prostě proxy podívá do hlaviček, zda tam jsou přihlašovací údaje, a když ne, vrátí stavový kód, prohlížeč si vyžádá jméno a heslo a pak už všechny požadavky posílá spolu s nimi. Takže to původní aplikaci nemůže nijak ovlivnit.

Když budete chtít dělat captive portál, musíte uživatele buď přesměrovávat jinam, nebo na té původní adrese zpřístupnit přihlašovací stránku. V obou případech to může způsobit nějaký konflikt s tou původní aplikací – třeba zvolíte název souboru, který používá ta původní aplikace apod.

Ale pokud se do toho chcete pustit, třeba pro Caddy jsou pluginy, které umožňují napojit do Caddy různé formy autentizace. Třeba Caddy Security.