Příspěvky

5596

Sítě / Re:Levné zařízení pro Wi-Fi komunikaci

« kdy: 05. 11. 2013, 13:15:35 »

Proste potrebuji LAN to WiFi dongle nejlepe s PoE.

To je sice hezké, že přesně tohle chcete, ale ten název toho zařízení jste si vy vymyslel, takže nikdo nic takhle nazvaného nevyrábí. Vyrábějí se zařízení se stejnou funkčností, akorát se jim říká jinak – WiFi access point (AP) nebo WiFi router. Vybírat můžete třeba zde: Access pointy, Mikrotik AP, Access point. Ty lepší mívají i PoE. Akorát pro PoE musíte mít i napájecí stranu, to vám nebude fungovat tak, že kamkoli přijdete, připojíte se do místní LAN a budete mít PoE napájení.

5597

Sítě / Re:Levné zařízení pro Wi-Fi komunikaci

« kdy: 05. 11. 2013, 11:19:20 »

Vyuziji toto tema - omlouvam se zakladateli.

Proč? Kdybyste založil nové téma, nevzniká tady zmatek, nemusíte s enikomu omlouvat…

Vite o nejakem wi-fi modulu-dongle, ktery se pichne do LAN nejlepe s POE (neni podminkou)? Dik.

Třeba TP-LINK TL-WR702N? http://www.czc.cz/tp-link-tl-wr702n/105680/produkt napájení není PoE, ale microUSB. Ale nevím, co vlastně chcete. Kdybyste napsal, jaký problém řešíte, ne jak si představujete řešení, určitě by vám někdo dokázal poradit lépe. Zařízení, které se připojí do LAN a vytvoří WiFi síť, nebo které se opačně připojí do WiFi sítě a další zařízení se přes LAN připojují k němu, se obyčejně nazývá WiFi router nebo AP, a jsou jich miliony v každém e-shopu.

5598

Server / Re:HTTPS na webovém rozhraní FatRat

« kdy: 11. 10. 2013, 18:16:50 »

Podle zdrojáků je HTTPS ve webovém rozhraní podporované až od verze 1.2.0, a certifikát se pak vytváří a instaluje přímo z FatRatu.

5599

Server / Re:Jak zprovoznit HTTPS na FatRat webovém rozhraní

« kdy: 11. 10. 2013, 08:50:39 »

V tom FAQ se píše, že se to dělá přímo přes webové rozhraní FatRatu. To jste nezkoušel?

5600

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.

5601

/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í.

5602

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.

5603

Odkladiště / Re:Nejlevnejsi uznavany S/MIME elektronicky podpis

« kdy: 19. 09. 2013, 10:13:54 »

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…

5604

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

5605

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.

5606

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 :-)

5607

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).

5608

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é?

5609

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 :-)

5610

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ů).