reklama

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 ... 213 214 [215] 216
3211
Software / Re:e-podání x e-podání
« kdy: 02. 10. 2013, 19:12:40 »
posílat nějaké dokumenty firmě, která vede spor se státem přes datové schránky, které jsou pod kontrolou státu.
Kdyby pod kontrolou státu. Ony jsou pod kontrolou soukromých firem. Pošlete reklamaci České poště přes datové schránky, oni budou tvrdit, že nic nedostali, a u soudu budete chtít od Pošty potvrzení, že Pošta tu zprávu dostala.

3212
/dev/null / Re:CZC, aneb už mne tam neuvidí!
« kdy: 02. 10. 2013, 14:14:57 »
me u nich zase stve jak si clovek obedna zbozi kde zelene sviti skladem vice jak x kusu
a pa kdyz pride na prodejnu tak mu reknou ze to skladem sice maj, ale jenom nekde v kotehulkach.. nechapu kdo tu zelenou ikonku u neceho co neni skladem vymyslel!!.
Jak byste si to jinak představoval? Že tam bude svítit zelená jenom tehdy, když to mají na všech skladech? Nebo z křišťálové koule uhodnou, kam se pro to chystáte, a zobrazí ten sklad? Já zase nechápu, že si stěžuje někdo, kdo na tu zelenou ikonku neumí kliknout, aby se dozvěděl, kdy zboží kde bude k vyzvednutí.

3213
Software / Re:ČSSZ a e-podání v GNU/Linuxu
« kdy: 30. 09. 2013, 17:32:52 »
A i kdyby o rok později nebylo vyhnutí, stále ještě můžete papírový formulář oskenovat a na Czech Pointu jej za drobnou úplatu poslat datovou schránkou ČSSZ.
To nestačí, protože podání by v takovém případě nebylo v zákonem požadovaném formátu. Vytvoření toho elektronického podání v patřičném formátu se vyhnout zřejmě nepůjde (zatím od roku 2015, pokud se to zase neposune), vyhnout se lze nutnosti použít datovou schránku nebo elektronický podpis -- stačí poslat podání elektronicky bez el. podpisu a následně poštou potvrdit, že jste takové podání podal.

Ta závislost na 602FormFilleru se mi taky nelíbí, ale nenapadá mne žádný zákon, který by to výslovně porušovalo. Malé zlepšení oproti dřívějšku je aspoň to, že už vzali na vědomí Linux – i když si nedělám moc iluze o tom, jak ten oficiální bastl 602FormFilleru a Wine asi bude spolehlivě fungovat na nejrůznějších distribucích.

3214
LOL, Comodo? To si jej uz rovnou muzes vydat sam. Zrovna tahle CA opravdu neni moc duveryhodna...
Tazatel nechtěl certifikát od důvěryhodné autority, ale od takové, jejíž certifikát má nainstalováno co nejvíc lidí, kteří certifikáty CA nijak neřeší a používají to, co jim dodá (snad) distributor jejich softwaru…

3215
Vývoj / Re:Šifrovací algoritmus pro hesla
« kdy: 19. 09. 2013, 08:25:40 »
Požadavek na to, aby se nedalo znovu přihlásit odposlechnutím přihlášení jste na začátku nenapsal…

V takovém případě je potřeba určitá spolupráce klienta. Server vygeneruje náhodná data (výzvu) a zašle ji klientovi. Klient vytvoří hash hesla a výzvy a výsledek odešle serveru. Ten z uloženého hesla a výzvy vytvoří také hash a porovná jej s tím, který dostal od klienta.

Místo otevřeného hesla (aby je server nemusel znát) je možné použít osolený hash hesla. Pokud by byla sůl pro každého uživatele jiná, musel by klient nejprve požádat server o sůl + výzvu pro konkrétního uživatele, a na základě toho vypočítat odpověď. Nebo je možné použít jednu sůl pro celý server – pak klient posílá přihlašovací jméno a hash najednou. Nevýhoda takového řešení je v tom, že pokud budou mít dva uživatelé stejné heslo, na serveru bude uložen i stejný hash. Tenhle způsob autentizace se používá např. v přihlašování přes HTTP metodou Digest: http://en.wikipedia.org/wiki/Digest_access_authentication

3216
Vývoj / Re:šifrování hesla
« kdy: 18. 09. 2013, 18:57:28 »
tak to potom nemůže splňovat tento požadavek
- při každém šifrování řetězce/hesla vygeneroval jiný řetězec

Já to pochopil tak, že chce, aby mu po zašifrování/hashování řetězce "ahoj" vyšlo pokaždé něco jiného.

Uživatel si zvolí heslo, vy vytvoříte náhodnou sůl, vypočítáte heslo+sůl -> hash a uložíte si sůl+hash. Při ověření uživatel zadá heslo, vy si načtete sůl a hash, vypočítáte heslo+sůl -> hash a porovnáte jej s uloženým hashem. Sůl se tedy nevolí náhodně pokaždé, ale jen poprvé při registraci hesla. Při ověřování už se používá ta sůl, kterou máte poznamenanou spolu s hashem.

3217
Sítě / Re:Android JB neodpovídá na ping
« kdy: 02. 09. 2013, 13:43:46 »
Musí mít nějak dobře vychytané aby udržování toho trvalého spojení nežralo moc baterky a fungovalo i během deep sleep.
K tomu podle mne stačí udržovat tu aktivitu spojení ze strany telefonu a tam k tomu stačí obyčejný budík. Nejsložitější je podle mne vyladit ten interval tak, aby nějaké NATy a filtry u operátorů ta spojení neztrácely. Ale Google má dost velký testovací vzorek uživatelů, na kterém to mohl vyzkoušet a odladit :-)

3218
Sítě / Re:Android JB neodpovídá na ping
« kdy: 02. 09. 2013, 09:49:51 »
Ano, tento vysokoúrovňový přehled se dá vyčíst z odkazu co sem uvedl. Ta zásadní otázka je jak je technicky vyřešeno to, že ten push server je schopen to na telefon dotlačit i když ten spí.
Vývojář z Google, který tu push službu (dnes se jmenuje Google Cloud Messaging) vytvořil, tvrdil, že používají dlouhotrvající spojení. Chápu to tak, že mobil naváže TCP/IP spojení se servery Googlu, kterým normálně neproudí žádná data (nanejvýš občas nějaký keep-alive paket). Když je potřeba doručit notifikaci na telefon, pošle se právě tímhle spojením. Protlačení na telefon je pak úplně standardní doručení paketu přes GSM síť – je to obyčejný paket, který je součástí aktivního TCP/IP spojení (které akorát shodou okolností dlouho nepřenášelo žádná data).

3219
Server / Re:Hosting na VPS a SSL certifikáty
« kdy: 22. 08. 2013, 10:15:18 »
Specifické případy bych zobecnil na použití jakéhokoliv SSL/TLS (nejen s SNI). Nativní implementace (pomocí OpenSSL) je pořád ještě rychlejší a hlavně flexibilnější než JSSE.
To je dohad, nebo je to něčím podložené?

3220
Server / Re:Hosting na VPS a SSL certifikáty
« kdy: 22. 08. 2013, 07:43:13 »
podle stránky na wikipedii věnované SNI by to měl podporovat Tomcat na Java 7
Já bych na to moc nesázel, bůhví, co to znamená. Třeba to může fungovat při použití AJP nebo reverzní proxy, kdy to SNI za Tomcat vyřeší předřazený server. Co jsem jenom prolétnul zdrojáky, má Tomcat také nativní implementaci SSL přes JNI, možná to řeší tam.

To neřeš, postav před to libovolnou reverzní proxy (Apache, NGINX, Lighttpd), která SSL spojení zakončí a na aplikační server to půjde už nešifrovaně.
Pokud potřebuje SNI a javovské aplikační servery to neumí, pak ano. Ale obecně bych to nedělal, je to jen další zbytečný server, který ve většině případů nic nepřináší. Ono se traduje ještě z doby, kdy byla implementace v Javě bídná, že před javovským aplikačním serverem má být předřazený web server, ale to už podle mne dávno neplatí. Až na specifické případy jako SNI :-)

3221
Server / Re:Hosting na VPS a SSL certifikáty
« kdy: 21. 08. 2013, 08:07:28 »
Ale jaký konkrétní certifikát předloží se server který podporuje SNI rozhodne na základě hostname které mu klient pošle (právě pomocí SNI).
Jasně, máte pravdu. Omlouvám se za mystifikaci, neuvědomil jsem si, že celý vtip spočívá v tom, že na serveru není jeden certifikát, ale několik.

Tak podle webu ani Java 7 nepodporuje SNI na serverové straně. Na druhou stranu, výběr certifikátu je záležitost aplikačního kódu (i když Glassfish už v sobě má nějakou implementaci), takže pokud jsou informace ze SNI někde v SSLSession nebo něčem podobném dostupné, mohl by se podle nich váš kód rozhodovat. Ale nebylo by nic jednoduchého to naprogramovat (ono už samotné JSSE samo o sobě je peklo) – ono asi má nějaký důvod, že se do toho zatím nikdo nepustil (ani u opensource projektů).

3222
Server / Re:Hosting na VPS a SSL certifikáty
« kdy: 20. 08. 2013, 20:26:16 »
nevíte někdo jak je to s podporou SNI v Glassfishi?
Podle mne SNI server nijak nezajímá -- server certifikát jenom předloží klientovi, ale jeho obsah nemá důvod zkoumat. Jinak by to stejně nebyla záležitost Glassfishe, ale SSL implementace v Javě, respektive JSSE (Java Secure Socket Extension). Java od Oracle podporuje SNI od Java 7 Update 2. Ale to se týká klienta.

3223
Odkladiště / Re:Autentizace na daňový portál
« kdy: 12. 08. 2013, 19:50:28 »
"Signing data with your private signature key" nevypadá jako žádost, ale spíš jako informace o tom, co už probíhá. Potvrzení podle mne probíhá v tom kroku "na žádost vložit smart kartu a odkliknout". Přístup ke kartě zůstává ve Windows v rámci aplikace po určitou dobu platný, tj. pokud do aplikace jednou zadáte PIN, nějakou dobu ho nemusíte zadávat znovu. A především, celý podpis je záležitostí především ovladačů příslušné smart karty (a samozřejmě jejich komunikace se samotnou kartou), aplikace jen nastaví parametry (algoritmus, délka klíče) a pošle podepisovaná data, nic dalšího ale ovlivnit nemůže.

3224
Vývoj / Re:Odchycení kláves 2-0 v Javě
« kdy: 06. 08. 2013, 10:27:13 »
Chtělo by to vyzkoušet, zda to v tom Linuxu dělá Java, nebo XKB. Určitě bych se podíval na výstup příkazu xev – ale ten myslím zobrazuje vstup do XKB, nikoli výstup, takže pokud bude zobrazovat kódy správně, ještě to nemusí znamenat, že problém není v XKB. Možná v XKB budou další utility, se kterými půjde zjistit, co z XKB leze.

Pokud zjistíte, že z XKB lezou očekávaná data, a zkazí to až Java, bude podle mne ještě důležité, zda je to „originál“ Java od Oracle, nebo zda je to třeba OpenJDK.

3225
Vývoj / Re:Odchycení kláves 2-0 v Javě
« kdy: 06. 08. 2013, 08:03:34 »
Za prvé, pokud jste ještě neobjevil příkaz switch, do nízkoúrovňového programování bych se být vámi nepouštěl.

Za druhé, vůbec nepíšete, jakým způsobem klávesy zachytáváte. Na úrovni operačního systému je to tak, že se detekuje stisknutí a uvolnění klávesy, a posílá se kód konkrétní klávesy. O úroveň výš se pak dělá mapování na znaky – takže třeba kombinace dvou kláves se přemapuje na jeden znak, řeší se opakování znaku při držení klávesy atd. Nad tímhle vším pak je ještě Java, která to zase zevšeobecňuje pro multiplatformní programy. Takže je otázka, co všechno je v Javě dostupné.

Za třetí, když si přečtete JavaDoc (bez toho se vůbec nepouštějte do programování v Javě), dočtete se tam, že máte zpřístupněné ty výše zmíněné dvě úrovně. KeyCode se posílá jen při stisknutí a uvolnění klávesy (nižší úroveň zpracování), při události keyTyped už je nastaven na nulu (protože došlo k mapování na znaky a znak je často výsledkem stisku více kláves). A přesně takhle mi to také funguje. Můžete si to sám vyzkoušet:
Kód: [Vybrat]
public class KeyEventTest extends JFrame implements KeyListener {

  @Override
  public void keyTyped(KeyEvent event) {
    printEvent("Typed", event);
  }

  @Override
  public void keyPressed(KeyEvent event) {
    printEvent("Pressed", event);
  }

  @Override
  public void keyReleased(KeyEvent event) {
    printEvent("Released", event);
  }

  private void printEvent(String eventName, KeyEvent event) {
    System.out.println(String.format("%s: %c %d %d", eventName, event.getKeyChar(), event.getKeyCode(), event.getKeyLocation()));
  }

  public static void main(String[] args) {
    new KeyEventTest().setVisible(true);
  }

  public KeyEventTest() throws HeadlessException {
    super("KeyEvent");
    setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
    setMinimumSize(new Dimension(200, 200));
    addKeyListener(this);
  }
}

Stran: 1 ... 213 214 [215] 216

reklama