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 ... 156 157 [158] 159 160 ... 375
2356
Hardware / Adaptér HDMI (Display Port) → USB-C
« kdy: 18. 08. 2019, 11:11:35 »
Existuje adaptér, který by měl na vstupu HDMI (a napájení) a na výstupu USB-C (tedy Display Port skrze USB-C)?

Existuje možnost signál Display Port poslat skrze USB-C port. Podporují to např. Mac Booky nebo telefony od Samsungu – mají jen USB-C port, k němu je ale možné připojit externí monitor (buď přímo, pokud monitor podporuje USB-C, nebo skrze redukci USB-C → HDMI). Mne ale zajímá opačná situace – starší zařízení s HDMI výstupem, a možnost k němu připojit displej, který má jen USB-C vstup (používá tedy právě přenos Display Port signálu přes USB-C). Výhoda takového displeje je, že se připojuje jenom tím jedním USB-C kabelem, odkud si bere i napájení.

Google nepomáhá, protože ignoruje požadovaný směr signálu a pořád vrací samé redukce z USB-C na HDMI…

2357
Sítě / Re:iptables nat a udrzovani session
« kdy: 18. 08. 2019, 08:44:38 »
Nebylo by lepší řešit příčinu, tedy co divného se děje s tím TCP spojením, že mají servery potřebu posílat ACK ještě hodinu po ukončení komunikace?

Jinak timeouty pro conntrack se nastavují pomocí sysctl – pomocí
Kód: [Vybrat]
sysctl -a --pattern nf_conntrack
si vypište aktuální nastavení, uvidíte tak, co můžete změnit.

2358
Odkladiště / Re:Google ranking
« kdy: 18. 08. 2019, 08:33:05 »
takze, ak ludia na web klikaju vo vysledkoch google ovplyvnuje to pozitvne ranking ?
Ne. Google občas vkládá měřicí kód, kterým zjišťuje, na které odkazy ve výsledcích vyhledávání lidé klikají, ale to používá jen pro optimalizaci vyhledávače, není to vstup pro výpočet Page Ranku.

ak nie tak potom aj kampan za stvoky tisic je iba dacasna vec..
Dočasná věc by bylo hlavně to, pokud by se vám podařilo hacknout algoritmy Googlu a dostat se ve výsledích vyhledávání nahoru bez hodnotného obsahu. Občas se to někomu povede, je na výsledcích vyhledávání Googlu závislý, a pak Google změní algoritmus, některé podvodníky eliminuje a ti pak všude brečí, jak je ten Google podrazil.

Vy se ptáte na to, jak máte podnikat v konkurenčním prostředí. Buď nabídnete něco unikátního, to unikátní pak budete propagovat a budete lákat lidi, kteří o tu unikátnost mají zájem. Nebo se pustíte do vysoce konkurenčního prostředí, kde totéž dělají tisíce dalších – pak se ale nemůžete divit, že budete jeden z tisíců.

Navíc se na to ptáte na úplně špatném fóru, tady jsou technicky orientovaní lidé, vy se ptáte na SEO (search engine optimization) – to se ptejte třeba na WebTrhu.

takze chcete povedat ze rozbehnut akykolvek eshop s produktami co sa uz predavaju je nerealne?
Není to nereálné, ale pokud vytvoříte e-shop, který bude stejný, jako tisíce jiných, musíte počítat s tím, že prostě budete jeden z tisíců – i v těch výsledcích vyhledávání. Vy se na to díváte ze svého úhlu pohledu,ale zkuste se na to podívat optikou kohokoli jiného. Proč by zrovna ten váš e-shop měl být ve výsledcích vyhledávání nahoře, když existuje spousta dalších e-shopů, které jsou z pohledu zákazníků úplně stejné, jako ten váš? Pokud by existovala nějaká magická formulka, kterou byste se ve výsledcích dostal nahoru, navíc by vám tu formulku poradil někdo na Rootu – nenapadlo vás, že by tu stejnou formulku použily i ostatní e-shopy a byl byste zase tam, kde jste?

a co taka heureka?
Heuréka nabízí v rámci ČR dost unikátní služby, konkurentů má jen pár a co se týče množství uživatelů, jsou daleko za ní.

2359
Sítě / Re:Jak naroutovat
« kdy: 17. 08. 2019, 17:33:30 »
Jenom s těmi dvěma připojeními by to šlo udělat jedině v případě, že by ISP, přes kterého půjde upload, nekontroloval, zda jsou zdrojové IP adresy paketů z jeho rozsahů. Pak byste jednoduše pro veškerou komunikaci používal IP adresu ISP, přes kterého má jít download (tj. odpověď by šla přes ISP pro download), ale pakety byste ve skutečnosti odesílal přes ISP pro upload (na něj byste nastavil výchozí bránu).

2360
Server / Re:Kam ukládata zálohy
« kdy: 14. 08. 2019, 19:40:26 »
Je bezpecne zalohovanie na servery (disky) tretich stran ?
Ano.

2361
Čili data, která přijdou na server bych neměl na vstupu nijak kontrolovat/odescapovávat a normálně je rovnou uložit do databáze? Čili na serveru nemusím dělat žádnou kontrolu vůči XSS útokům? Nebo to mám zkontrolovat (udělat escapování) těsně před tím, než pošlu data na view? Nebo poslat ta data přímo z DBa udělat escapování a kontrolu těch dat až na view při renderování dat?
Na vstupu byste data měl kontrolovat – tj. pustit dál jenom taková data, která mají smysl, platné hodnoty. Třeba pokud někde má být věk v letech, musí to být nezáporné celé číslo, a je rozumné alespoň s varováním kontrolovat i nějakou horní hranici. Ale ne escapovat – pokud uživatel zadává např. obyčejný text, je posloupnost <script> legální posloupností (co když uživatel třeba bude posílat část svého kódu). Escapovat je nutné na výstupu – aby se zobrazilo zase <script>, co zadal uživatel, a ne aby se místo toho vložil do HTML skutečný skript.

Escapování by se mělo ideálně dělat až ve view při renderování dat. Rozumné knihovny pro view jsou dokonce navržené tak, že ve výchozím nastavení samy escapují a pokud escapovat nechcete, protože máte příslušná data ošetřená jinak, musíte to speciálně zadat. Pokud takovou funkci knihovna pro view nemá, musel byste escapovat před tím, než data pošlete do view. Ale tomu bych se snažil vyhnout, protože na to určitě někde zapomenete.

2362
Dočetl jsem se, že se má uvádět:
Content-Type": "application/x-www-form-urlencoded
Je nutné tento content-type mít vždy tento, nebo jen při autentizaci/refresh_token atd?

Mám problém s tím, že mi nejdou posílat requesty na server, když ta data jsou v body. Spring mi to nebere:
Resolved [org.springframework.web.HttpMediaTypeNotSupportedException: Content type 'application/x-www-form-urlencoded;charset=UTF-8' not supported]
Za předpokladu, že použiji:
application/json
Tak je vše v pohodě...
Content-Type určuje, v jakém formátu odesíláte data na server (a opačně v hlavičkách odpovědi říká, v jakém formátu je odpověď). Pro data posílaná v těle požadavku při OAuth je správný typ application/x-www-form-urlencoded – data se posílají, jako by to byl vyplněný HTML formulář. Spring by to v rámci autentizace měl zpracovat sám, pokud byste autentizaci implementoval sám, musí kontroler nakonfigurovat, aby tento typ dat přijímal (standardně Spring očekává data ve formátu JSON).

je nějaký doporučený způsob, jak se vypořádat s XSS na straně springu?
XSS byste měl řešit na straně view. Pokud uživatel na server odešle např. znak <, chce, aby se ten znak zobrazil – vy byste ho tedy měl normálně uložit do databáze. Při renderování obsahu ve view pak musíte zajistit, aby se speciální znaky escapovaly – např. < se musí vyrenderovat jako &lt; do zdrojového kódu HTML, protože ten znak má jinak v HTML speciální význam. Ale kdybyste chtěl ten samý text vyrenderovat třeba do PDF, nebudete řešit znak <, protože v PDF žádný speciální význam nemá.

Řešit to na straně vstupu je špatně, protože tím měníte data, která poslal uživatel – zobrazíte pak něco jiného, než poslal. Navíc pak očekáváte, že v databázi už máte všechna data vyčištěná a zobrazujete je bez escapování, což je dost „odvážné“. Navíc escapuje se podle použitého výstupního formátu, tj. jinak se escapuje pro HTML, jinak pro PDF, jinak pro čistý text – a třeba se jinak budou escapovat budoucí verze HTML. V databázi byste tedy měl mít uložen původní vstup od uživatele, protože nikdy nevíte, jak ho budete potřebovat escapovat v budoucnosti.

2363
Sítě / Re:Pevná IP adresa.
« kdy: 04. 08. 2019, 16:10:30 »
Ne dané věci moc nerozumím ptám se proto co bude výhodnější varianta pro přístup k nasu a k online hrám jestli mě nebude stačit ta levnějsí varianta ipv6 za 119 korun. https://www.o2.cz/osobni/pevna-ip-adresa-pro-internet-na-doma

Abyste mohl doma hrát online hry, pevnou veřejnou IP adresu nepotřebujete. Pokud chcete mít odkudkoli z internetu přímý přístup k domácímu NAS serveru, potřebujete veřejnou IPv4 adresu – ve spoustě sítí bohužel ještě není IPv6 dostupné, z takových sítí byste se domů nedostal.

Pokud ale O2 normálně dává veřejnou IPv4 adresu (akorát ne statickou), může vám pro přístup z internetu stačit nějaká služba typu DynDNS a pevnou veřejnou IPv4 adresu nepotřebujete. Přistupoval byste k NASu pomocí jména, a když se ta veřejná IP adresa změní, přeregistruje se (automaticky pomocí skriptu) to jméno na novou IP adresu, takže změnu nepoznáte.

2364
Sítě / Re:Pevná IP adresa.
« kdy: 04. 08. 2019, 14:49:14 »
Aj ked tazatel nepolozil otazku, tak asi vsetci vieme o co mu ide. Chce sa pripajat cez verejnu siet internet (ked bude niekde mimo svoju LAN) domov na svoje zariadenia.

Podpla mna IPv6 vznikol za tym ucelom, ze IPv4 pomalicky spotrebuvaval svoje IP adresy vyclenene pre verejny rozsah (ale stale ich je podla mna dost).
Pises o zakupeni pevnych IP adries (IPv4 alebo IPv6). Ak mas teraz tieto IP adresy verejne a nemas ich pevne pouzi nejaku DynDNS sluzbu.
IPv6 by mali byt vsetky verejne a ked chces verejnu IPv4, tak si ju musis zakupit
Vzhledem k tomu, že celý váš druhý odstavec je špatně, nespoléhal bych ani na to, že vy víte, co Jan Maryška chce, a počkal bych, až to napíše on sám.

Prosím může mi někdo poradit?
Můžeme, ale nejprve musíte napsat, jaký řešíte problém. A nepište „potřebuju veřejnou IP adresu“ – napište k čemu ji potřebujete, jaký problém řešíte. Na tom totiž závisí řešení.

2365
Jinak existují js knihovny, které tohle celé řeší a odstiňují od implementačních rozdílů v prohlížečích (teď si nevybavuji, socket.io vyžaduje node, to asi není ono).
Například STOMP.js, kterou používá i ten příklad ve Springu, který linkoval PetrK.

Potrebuju opravdu jenom jednu jedinou vec: knihovnu v javascriptu, abych si to nemusel zbytecne psat sam.
Sám jste odkázal na návod, kde už to máte celé naprogramované – jak serverovou část, tak tu klientskou s využitím knihovny.

Ta knihovna bude postavena rekneme nad jQuery a postara se mi o chytre redundantni naslouchani na Serveru. To je opravdu vsechno co potrebuju.
Jenže taková knihovna neexistuje, protože vaše řešení má spoustu problémů, takže to tak nikdo nedělá. Pokud to chcete udělat pomocí běžně používaných nástrojů, odkazy už jste dostal. Pokud to nutně potřebujete řešit sice špatně, ale po svém, budete si to muset napsat sám.

2366
Ja se na to jak to udelat pres Websocket dival:
https://spring.io/guides/gs/messaging-stomp-websocket/

neni to zbytecne slozite? Ten polling dokaze byt docela jednoduchy, jenom k tomu mit vhodnou knihovnu. Jakou pridanou hodnotu mi daji Websockety?
Přidaná hodnota je ta, že už to máte ve Springu implementované (včetně volitelného fallbacku na long-polling), je to vyzkoušené a funguje to. Včetně těch klientských knihoven.

Když si to budete implementovat sám, po nasazení do produkce zjistíte, že v reálném světě jde komunikace často přes nějaký NAT nebo proxyserver, které mají nějaké timeouty na dobu neaktivního spojení. Takže vám po nějakém čase spojení tiše uzavřou, a vy se to dozvíte až v okamžiku, když budete chtít ze serveru odeslat nějakou zprávu. Jenže to spojení potřebujete znovu navázat z klienta. Takže tu svou implementaci rozšíříte o nějaký mechanismus keep-alive.

Pak zjistíte, že mít na serveru jedno uspané vlákno pro každého připojeného klienta také není nejlepší nápad.

A takhle se vám ta docela jednoduchá implementace bude postupně komplikovat, a za chvíli budete litovat toho, že jste nepoužil to, co máte k dispozici „na pár kliknutí“. Zvlášť, když už teď máte aplikaci postavou na Spring MVC, takže nepotřebujete nic nového, stačí to nakonfigurovat a začít používat.

2367
Vývoj / Re:Váš názor na kombinaci několika technologií
« kdy: 03. 08. 2019, 14:04:20 »
Máte nějaké příklady (nejsem Groovista)? Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).
Já také Groovy používám jen občas na skriptování, a potom v Gradle. Exemplárním příkladem je podle mne volání metod – závorky, jsou nepovinné, pokud je kód jednoznačný, pokud je poslední parametr closure, může být uvedený až za závorkami, volání setterů a getterů můžete napsat jako přiřazení/čtení do/z fieldu. Jasně, všechno to šetří „zbytečné“ psaní… Ale když jsem začínal s Gradle, tenkrát byla navíc ještě doporučovaná syntaxe s přetíženým operátorem <<, strašně těžko se mi orientovalo v dokumentaci a příkladech, protože jsem neustále musel pracně luštit, co je to vlastně za kód – je to volání metody? Je to přiřazení? Je to closure? Jasně, není to úplně čisté Groovy, Gradle je spíš další jazyk postavený nad Groovy a možnosti Groovy využívá do krajností. Ale o to více to vyniklo. Tím, že Groovy jinak používám pouze pro své skripty, bylo to vlastně poprvé, kdy jsem musel číst větší množství kódu napsaného v Groovy někým jiným. A díky tomu jsem si uvědomil, co mi na Groovy vlastně vadí. Ale pro soukromé skriptíky je fajn, stejně jako kdysi Perl.

2368
WebSockety. Ve Springu pro to máte podporu: Web on Servlet Stack – WebSockets nebo Web on Reactive Stack – WebSockets.

2369
Vývoj / Re:Váš názor na kombinaci několika technologií
« kdy: 03. 08. 2019, 12:11:02 »
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.
Podle mne je to tím, že přístup k syntaxi je v Groovy je přesně opačný než v Javě. Java je založená na tom, že každá věc se dělá právě jedním způsobem, takže když dva programátoři budou psát totéž, napíšou stejný kód. (Samozřejmě to neplatí úplně stoprocentně, ale v Javě je tenhle rys hodně silný.) Groovy naopak dává programátorovi spoustu možností, jak napsat jednu a tu samou věc. Takže když píšu nějaký kód, můžu ho napsat přesně tak, jak by se mi to líbilo. Problém ovšem je se čtením takového kódu. Groovy mi tímhle připomíná Perl… Jako skriptovací jazyk je Groovy super, closures zavedl dávno před tím, než měla Java lambdy, ale ta rozvolněná syntaxe je podle mne pro lidi zvyklé na Javu spíš matoucí. Je otázka, zda by se Groovy neuchytilo třeba spíš u lidí zvyklých na JavaScript.

2370
Server / Re:Ansible vs. bezpečnost
« kdy: 01. 08. 2019, 11:15:36 »
Co by se tedy místo sudo mělo používat? Jak by měl správce ideálním případě postupovat?
Bavíme se o správě serverů? Pak místo sudo nepoužívat nic. Správce se přihlásí jako root, žádné sudo tedy nepotřebuje. Pokud chce správce dělat něco, k čemu nepotřebuje rootovská oprávnění, ve vedlejším terminálu se přihlásí jako běžný uživatel.

Stran: 1 ... 156 157 [158] 159 160 ... 375