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 ... 235 236 [237] 238 239 ... 375
3541
A prave JS jim umoznuje tvoji adresu zjistit
Jak?

3542
Vývoj / Re:Abuzus XML v Javě
« kdy: 14. 02. 2018, 13:56:45 »
Heh, muzu vedet, co je tak sloziteho, kdyz do Entity beanu pridam :
Přidávat něco do neexistujícího entity beanu je podle mne docela obtížné. Docela by mne zajímalo, jak to děláte. Ale spíš si myslím, že jste pořád ještě nepochopil, že celý ten váš entity bean je zbytečný a já se bez něj obejdu.

Ne, neni. Testovano osobne.
To, že vy něco neumíte, neznamená, že to nejde.

Kód: [Vybrat]
Source xslt = new StreamSource(new File("template.xsl"));
Source input = new StreamSource(new File("input.xml"));
Result output = new StreamResult(new File("output.xml"));
Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt);
transformer.transform(xml, output);

Co je na tom složité?

Ehm, mluvime tady jaksi v urcitem kontextu.
A v kontextu webu, kde dneska vladne Javascript (a AJAX Primefaces je jenom priklad, klidne mozno dosadit REACT) znamena, ze XSLT transformace pro WEB je k nicemu.
To, že se někde používá AJAX, neznamená, že musí být všude. Pokud potřebuju vygenerovat nějaký report z relační databáze, je výstup z databáze do XML a následná XSLT transformace do HTML5 to nejjednodušší, co můžu použít, a nemusím to komplikovat AJAXem a RESTem a frameworky na tohle a na tamto. Výsledná stránka bude krásně jednoduchá, nebude potřebovat žádný JavaScript a upravit jí bude znamenat oeditovat jeden soubor na serveru.

3543
Vývoj / Re:Abuzus XML v Javě
« kdy: 13. 02. 2018, 22:44:25 »
Opravdu netusim, co je tak pracneho na naplneni beanu z radku resultsetu.
Já netuším, kde jste sebral, že je to pracné. Já jsem psal, že je pracně vytvářená Java beana – i když jí budete vytvářet a udržovat synchronní s databázovým schématem nějakým automatickým nástrojem, pořád je údržba té beany pracnější, než žádná beana.

Samotna XSLT transformace je narocnejsi task.
Naprogramovat je to stejně snadné, jako to naplnění beanu z resultsetu, za běhu to také není nijak náročné.

zatez Tomcatu znatelne vyssi, nez hloupe JSP stranky se zakladnimi <c:> tagy.
JSP se kompiluje do Java bytekódu. Placené verze Saxonu umí kompilovat i XSLT.

A dneska je XSLT uplna blbost, v dobe JSF2 knihoven typu Primefaces.
Spíš to vypadá, že nevíte, co je XSLT. Když potřebuju jenom data zobrazit podle svého, nepotřebuju tam tahat JSF – zvlášť když to chci zobrazit třeba jako PDF, u čehož mi JSF nepomůže vůbec nijak.

3544
Vývoj / Re:Abuzus XML v Javě
« kdy: 13. 02. 2018, 07:10:10 »
Vy z nějakého důvodu předpokládáte, že se s tím XML bude pracovat jedině přes objekty v Javě. Přitom jste sám napsal o vložení XML do databáze, a k tomu opravdu žádnou Javu nepotřebujete. S XML můžete pracovat pomocí XSLT, XQuery, XProc, můžete ho uložit do XML databáze, i v té Javě s ním můžete pracovat pomocí DOMu.

Mně zase připadá zvrácené, když se data z relační databáze mapují na pracně vytvářené Java beany, aby se vzápětí serializovaly přes nějaký šablonovací systém do HTML. Přitom výsledek dotazu do relační databáze se dá snadno serializovat do XML (některé databáze pro to mají přímo vestavěnou podporu), a to se dá pomocí XSLT transformovat rovnou do HTML.

3545
Doporučuji ještě jednou se podívat na název domény, z níž je ten „článek“, který sdílíte. Je to známý dezinformační web, takže to, co se tam píše, je s největší pravděpodobností snůška lží, polopravd a výmyslů. Ve slušné společnosti se na takovéhle weby neodkazuje.

3546
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 22:06:04 »
Podla novely zakona o autorskom prave moze poziadat o dodatocnu odmenu za poskytnutie licencie. Podla toho isteho zakona moze licenciu zrusit ak autorske dielo nie je dostatocne vyuzivane a tym padom by bola odmena zanedbatelna. Tieto paragrafy nie je vdaka tej novele v zmluve o vyhradnej licencii zrusit.
Které je to ustanovení, nebo která novela? Navíc licence poskytnutá Abíčku není výhradní…


3547
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 15:00:15 »
Nepovolit vložit více jak jeden příspěvek za minutu pro NEREGISTROVANÉ je IMHO zcela nerestriktivní věc. A klidně globálně. Samozřejmě z jedné IP adresy. Pochybuji, že by se tam sešlo více žhavých diskutérů kdesi za NATem, které by to mohlo omezovat.
Aha, takže ne globálně, ale z jedné IP adresy. Různých anonymních proxy serverů jsou stovky, to samé TOR exit nodes, takže byste spammerovy dovolil vkládat jen stovky, možná tisíce komentářů za minutu. Opravdu si myslíte, že by to pomohlo?

Už to, že se tam může kdo chce vydávat za koho chce
Na to jste přišel jak?

Tady už někoho lynčujete a přitom by stačilo, kdyby si provozovatel aktivoval aspoň elementární ochranu proti spamu.
Proč pořád píšete o věcech, o kterých vůbec nic nevíte? Obrana proti spamu není nějaké tlačítko, které máte přidělané na počítači od výrobce a jenom ho přepnete do polohy zapnuto. Obranu proti spamu musí nejprve někdo do aplikace naprogramovat, teprve pak ji může někdo „aktivovat“. Přičemž to pracné na tom samozřejmě není aktivace, ale právě to naprogramování. A nejprve vůbec musíte vymyslet, jak se vůbec spamu bránit – ty vaše nápady, že „omezíte“ útočníka na několik tisíc příspěvků za minutu, nevypadají zrovna moc použitelně.

3548
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 13:59:05 »
A je problém třeba omezit vkládání na 1 příspěvek za minutu?
Zdrojáky jsou veřejně dostupné, nic vám nebrání napsat patch. Je zvláštní, že se ani neumíte do těch zdrojáků podívat, ale víte, že je to jednoduché.

Mimochodem, myslíte 1 příspěvek za minutu globálně? Řekl bych, že i v dnešní době je tam provoz často vyšší. Nebo jste myslel 1 příspěvek za minutu třeba z jedné IP adresy?

Nepřesvědčíte mě, že adminové co to tam vedou jsou neschopní nýmandi.
Píše někdo, kdo není schopen rozlišit mezi administrací systému a úpravou aplikace.

Pokud vím, o server se tam teď stará jeden člověk, o aplikaci nikdo.

3549
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 13:45:11 »
Přesně. Už jenom ta captcha co tam mají.... Prý aktuální rok???? Je to normální? Ani se to nemění... Ten web programovalo desetiletý dítě, nebo je z roku 1990
Ne, je z roku 2002. To byla ještě doba, kdy si lidé na internetu chtěli pomáhat, ne škodit.

3550
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 12:58:32 »
Je to ostuda, že mají web v takovém stavu. Linuxoví odborníci a neumí si zabezpečit server proti tak primitivnímu spamu?
Linux je operační systém. Proti spamu se zabezpečuje webová aplikace, v případě Abíčka je to Javovská aplikace psaná na míru. Tedy to s Linuxem nijak nesouvisí, ostatně ta aplikace Abíčka klidně může běžet i na Windows nebo jiném OS.

3551
/dev/null / Re:Co se děje s ABCLinuxu?
« kdy: 08. 02. 2018, 12:19:22 »
Jeden z tamních trollů spamuje. Abíčko na to není připravené, odmazávání znamená dost ruční práce. Přepnutí do režimu údržby znamená, že se Abíčko přepne do readonly režimu, čímž se spamerovi zabrání ve spamování a správce má čas to nějak řešit.

3552
Nemají prohlížeče nějakým způsobem standardizovaný přístup ke smartcard?
Nemají. Prohlížeče umožňují použít privátní klíč na kartě (buď přes systémové úložiště nebo přes PKCS#11) pro klientskou autentizaci klientským certifikátem v HTTPS, ale i to je interní věc prohlížeče, nijak to není přes API zpřístupněné webové stránce. Pak existuje Web Crypto API, které snad bude v budoucnosti řešit i podepisování, ale dnes je z toho reálně použitelná snad jen žádost o vydání nového certifikátu.

3553
Pro tazatele: v onom čase okolo 5. minuty se nic zásadního s privátním klíčem neděje, je použit k podpisu. Onen klíč je pořád v (lokálním) počítači. Směrem do internetu z lokálu odchází ověřená zpráva.
To si myslíte, nebo jste ověřoval zdrojové kódy té aplikace a máte ověřeno, že každý, kdo tu aplikaci používá, používá verzi sestavenou z vámi ověřených zdrojových kódů?

Tazateli samozřejmě reálně nic jiného nezbývá, než ten privátní klíč té aplikaci poskytnout. Ale je správně, že ho to zarazilo, a je správně mu napsat, že opravdu poskytuje svůj privátní klíč aplikaci, o které nic neví, což je špatně – a že správně by to tak být nemělo.

Já nezpochybňuju to, že se ta aplikace tak má chovat. Jenže jako autor velmi podobné aplikace jsem si vědom toho, že kdyby ta aplikace ten privátní klíč a heslo vzala a odeslal na server, drtivá většina uživatelů nemá šanci to zjistit.

A jinak to považuju především za problém webových prohlížečů, které se pořád snaží být platformou pro desktopové aplikace, implementují kde jakou hloupost, ale elektronický podpis neimplementují. Takže nám, autorům podepisovacích aplikací v prohlížeči, pak nezbývá než si JavaScriptem říct o soubor s privátním klíčem a heslo (což vůbec není bezpečné, a funguje to v ČR na naši národní výjimku – v rámci EU takový podpis není považován za věrohodný), a nebo se to musí řešit přes Javu nebo nativní plugin do prohlížeče (a pak zase spouštíte cizí kód a můžete jenom doufat, že podepíše opravdu to, co tvrdí, že podepisuje). Navíc nativní pluginy jsou pro každý prohlížeč jiné, s Javou je také problém, aby ji uživatel měl vůbec nainstalovanou, měl pokud možno aktuální verzi a měl správně nakonfigurovaný prohlížeč, aby se z něj Java WebStart aplikace spustila.

Jirsáka si nevšímej, to je zdejší tro*l, lepší je ho ignorovat, pokud možno několikrát.
Jistě, jedinou správnou odpověď v diskusi je nejlepší ignorovat. Kdybyste alespoň napsal, co konkrétně je podle vás na mé odpovědi špatně…

3554
je bezpečné vystavovat na "cizí" (i když v tomto případě se jedná o "důvěryhodný" SUKL) server export mého osobního podepisovacího certifikátu?
PFX není certifikát, ale privátní klíč – proto se s ním musí zacházet bezpečně. (Certifikát je veřejný.) Vy ten privátní klíč nevystavujete na cizí server, „pouze“ ho předáte cizí aplikaci, která na základě toho privátního klíče vytvoří elektronický podpis. Otázka tedy je, zda té aplikaci důvěřujete. Teoreticky by bylo vhodné, aby vždy bylo umožněné vytvořit elektronický podpis i vlastními prostředky, ale nevím, zda v tomto případě existuje podporovaný způsob, jak to udělat.

Že to vypadá jako klasické okénko pro upload je dané tím, že to je jediný způsob, jak v prohlížeči získat přístup k souboru.

3555
Hardware / Re:Stačí dvoujádro na vývoj v Javě?
« kdy: 06. 02. 2018, 14:15:48 »
Pro drtivou většinu aplikací (včetně vývoje) je mnohem důležitější velikost RAM než počet jader procesoru. Pokud nechcete programovat aplikace, které výrazně využívají paralelního zpracování, počet jader bych neřešil.

Stran: 1 ... 235 236 [237] 238 239 ... 375