Implementace protokolu XMPP v JavaScriptu

Transkrypt

1 České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů Diplomová práce Implementace protokolu XMPP v JavaScriptu Bc. Jan Brůček Vedoucí práce: Ing. Tomáš Novotný Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika leden 2011

2 ii

3 Poděkování V první řadě bych rád poděkoval Ing. Tomáši Novotnému za vedení této práce a za čas, který mi věnoval při konzultacích. Dále bych chtěl poděkovat Anně Mírové a své rodině za to, že mi byli oporou nejen při tvorbě této práce, ale i během celého studia. iii

4 iv

5 Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne v

6 vi

7 Abstract This work presents result of analysis and development of XMPP library under Mozilla Application Framework and its implementation as ExtBrain Communicator extension for Mozilla Thunderbird. Abstrakt Práce prezentuje výsledky analýzy a vývoje XMPP knihovny určené pro Mozilla Application Framework. Dále popisuje realizaci rozšíření poštovního klienta Mozilla Thunderbird nazvané ExtBrain Communicator, které využívá tuto knihovnu. vii

8 viii

9 Obsah Seznam obrázků xiv Seznam tabulek xv 1 Úvod 1 2 Specifikace cílů práce Vymezení cílů diplomové práce Požadavky na implementovaný systém Struktura práce ve vztahu k vytyčeným cílům Existující řešení v Mozilla Application Frameworku Sameplace Instantbird Spicebird Ostatní podobná řešení GTalk Facebook Analýza a návrh řešení XMPP Úvod Standardizace a XEPy Protokol IM komunikace a online stavy Message stanza Presence stanza IQ stanza Vyjednání spojení a jeho bezpečnost ix

10 Průběh SASL PLAIN autentifikace DIGEST-MD5 autentifikace Mozilla Application Framework JavaScript Komponenty frameworku Vytváření rozšíření Mozilla aplikace Chrome URL Chrome manifest a struktura add-onu ExtBrain Communicator XMPP knihovna Řešení více souběžných XMPP spojení Kontakty z adresářů a z rosteru Uživatelské rozhraní Vývojové prostředí a použité nástroje Realizace Knihovna XMPP Socket Analýza XML Parser Fragmentace Udržování spojení Zpracování přijatého DOM Napojení dalších komponent do XMPP kanálu DIGEST-MD Uživatelské rozhraní Seznam kontaktů x

11 Slučování kontaktů z adresáře a z rosteru Manipulace s kontakty Informace o kontaktu Konverzace Obsluha událostí Historie konverzací Okno nastavení Testování Testovací prostředí XMPP knihovna Uživatelské rozhraní Závěr 43 Literatura 45 A Diagramy a obrázky 47 B Seznam použitých zkratek 50 C Instalační příručka 51 C.1 Požadavky k instalaci C.2 Instalace ExtBrain Communicatoru D Uživatelská příručka 53 D.1 Nastavení účtů D.2 Nastavení zobrazovaných adresářů D.3 Připojení účtů D.4 Započetí konverzace D.5 Úprava kontaktu D.6 Sloučení kontaktu z rosteru s kontaktem z adresáře xi

12 D.7 Zobrazení historie konverzace E Obsah přiloženého CD 59 xii

13 Seznam obrázků 3.1 Příklad komunikace pomocí IQ stanz Mozilla Application Framework XPConnect, zdroj: [3] Instalace XPI balíku do Mozilla aplikace Návrh třídy XMPPSocket Návrh třídy XMPP Návrh třídy Jabber Návrh třídy Connections Návrh třídy Contact Uživatelské rozhraní hlavního okna Uživatelské rozhraní záložky s konverzací Uživatelské rozhraní nastavení Seznam kontaktů Box s informacemi o kontaktu Záložka s konverzací Modální okno nastavení A.1 Přechody mezi stavy připojování XMPP klienta, zdroj: [2] A.2 Návrh tříd pro XMPP knihovnu A.3 Návrh tříd pro práci s kontakty C.1 Okno Add-ons C.2 Potvrzení instalace C.3 Potvrzení instalace D.1 Okno Nastavení D.2 Seznam kontaktů D.3 Informace o stavu účtů D.4 Nastavení stavu jednotlivých účtů xiii

14 D.5 Kontextové menu kontaktu D.6 Záložka s konverzací D.7 Okno pro úpravu přiřazených JID xiv

15 Seznam tabulek 3.1 Struktura instalovatelného balíku rozšíření SQLite tabulka historie konverzace SQLite tabulka nastavení účtů xv

16 xvi

17 KAPITOLA 1. ÚVOD 1 1 Úvod V současné době zažíváme roustoucí trend v použití aplikací založených na výměně rychlých zpráv, tzv. instant messagingu. Známy jsou zejména díky zprostředkování komunikace mezi lidmi, avšak používané technologie nalézají uplatnění i v předávání zpráv mezi počítači a jinými elektronickými zařízeními. Hlavní výhodou těchto aplikací je tzv. real-time komunikace, tedy s minimálním zpožděním od odeslání do doručení zprávy. Historie internetového instant messagingu 1 se datuje již od konce 80. let 20. století, kdy jako jedna z technologií umožňujících rychlou výměnu zpráv mezi uživateli počítačů, vznikla sít IRC. Masovému rozšíření IM mezi běžné uživatele ale dopomohl až systém ICQ společnosti Mirabilis, který byl spuštěn v roce S podobnými produkty se na trhu objevily také společnosti America Online (AOL Messenger), Microsoft (MSN Messenger), IBM (Lotus Sametime) a další. Společnou vlastnosti všech zmíněných IM systémů je to, že používají proprietární protokol a klientské aplikace. Příliš limitující licenční podmínky a nutnost běhu separátní aplikace pro každý z IM protokolů proto v roce 1998 vedly Jeremie Millera k započetí prací na novém open-source protokolu, který pojmenoval Jabber [11]. Komunita vývojářů, která se později okolo projektu vytvořila, pak v květnu roku 2000 vydala první oficiální verzi nového open-source serveru jménem jabberd 1.0. Projekt měl u technické veřejnosti velký úspěch a vývojáři se rozhodli formalizovat používaný protokol u Internet Engineering Task Force (IETF), organizace, která vyvíjí a standardizuje internetové technologie. Pracovní skupina, která dostala tento protokol na starosti, ho pojmenovala Extensible Messaging and Presence Protocol, tedy zkráceně XMPP. Dnes je již XMPP 2 velmi vyspělým protokolem, celosvětově uznávaným standardem a používanou technologií nejen pro zasílání zpráv mezi lidmi pomocí počítačů, telefonů nebo sociálních sítí. Své využití nachází i v čistě strojové komunikaci pro cloud computing, vzdálený monitoring, ovládání zařízení připojených do sítě a podobně. Pro XMPP existuje velké množství klientů pro různé platformy, některé z nich dokonce podporují i více jiných IM technologií. Cílem této práce bude vytvořit klienta v prostředí Mozilla Application Frameworku, konkrétně pro aplikaci Mozilla Thunderbird. Mozilla Thunderbird je poštovním klientem neziskové organizace Mozilla Foundation, která zastřešuje vývoj několika internetových aplikací, jako je například webový prohlížeč Mozilla Firefox nebo právě zmiňovaný Mozilla Thunderbird. Mezi hlavní výhody aplikací Mozilla Foundation patří to, že jsou open-source a licencované třemi licencemi MPL/GPL/LGPL. 1 V textu bude použito zkrácené označení IM 2často také označováno zkráceně jako Jabber

18 2 KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE 2 Specifikace cílů práce 2.1 Vymezení cílů diplomové práce Hlavními cíli této práce jsou implementace XMPP protokolu v jazyku Javascript v prostředí Mozilla Application Frameworku a jeho následná integrace do existujícího rozšíření ExtBrain Communicatoru. Základním bodem bude realizace XMPP knihovny v Javascriptu, funkční v aplikaci Mozilla Thunderbird (resp. ve všech aplikacích, používajících Mozilla Application Framework). Tato knihovna bude zajišt ovat sestavení spojení s XMPP serverem včetně autentizací uživatele a bude poskytovat rozhraní pro přístup k takto vytvořenému kanálu. Dalším bodem bude vývoj rozšíření pro Mozilla Thunderbird, nazvaného ExtBrain Communicator. Práce bude částečně vycházet z již realizovaného rozšíření, které pod vedením Ing. Novotného vytvořil jako bakalářskou práci David Jirovec [7]. Toto rozšíření bude využívat XMPP knihovnu realizovanou v prvním bodě a poskytovat rozhraní pro IM komunikaci pomocí více XMPP účtů přímo v poštovním klientu Thunderbird. Později je také plánováno zařazení výsledku této práce do rodiny ExtBrain rozšíření, která si kladou za cíl co nejvíce zjednodušit kažodenní práci vývojářů softwaru při extrakci a manipulaci s informacemi [9]. 2.2 Požadavky na implementovaný systém Vytvořená aplikace bude používána jako rozšíření v poštovním klientu Mozilla Thunderbird. Bude poskytovat možnost připojení se do XMPP sítě, bude možné ji však také používat bez nastavených účtů jako panel, který slučuje kontakty z vybraných adresářů klienta do jediného seznamu, a který bude jednoduše filtrovatelný. Požadované vlastnosti lze shrnout do seznamu: XMPP knihovna bude podporovat zabezpečení spojení pomocí TLS, SSL. XMPP knihovna bude poskytovat rozhraní pro pozdější napojení dalších aplikací na kanál XMPP, tedy například integraci dalších rozšíření protokolu. Bude implementována správa více XMPP účtů najednou.

19 KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE 3 Bude implementován komunikační klient v prostředí Mozilla Thunderbird, který bude využívat vyvinutou XMPP knihovnu, a který bude umožňovat sloučení kontaktů z adresářů poštovního klienta a kontaktů z jabber účtů. 2.3 Struktura práce ve vztahu k vytyčeným cílům Tato diplomová práce je členěna do šesti kapitol vážících se k postupu při řešení problému. První kapitolou je úvod, kde se čtenář seznámí se základy technologií, které budou v práci použity. Další kapitolu tvoří popis a specifikace cílů práce. V ní se čtenář seznámí s řešeným problémem a požadavky na výsledné řešení. Navazuje kapitola obsahující analýzu a samotný návrh řešení. Zde se čtenář detailněji seznámí s technologiemi a s výsledným vybraným postupem pro implementaci. Další kapitolou je kapitola popisující samotnou implementaci projektu a zaměřující se zejména na nestandardní části aplikace. Předposlední kapitola obsahuje popis testování výsledného produktu této práce. V závěru práce je zhodnoceno dosažení vytyčených cílů práce a diskuse možného pokračování v implementaci vyvinutého projektu.

20 4 KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE 2.4 Existující řešení v Mozilla Application Frameworku Sameplace Sameplace je v současnosti jediný doplněk do Mozilla Thunderbirdu, který přidává možnost komunikace přes XMPP. Funguje však pouze pro verze Thunderbird 2 a zatím není známo, zda bude někdy k dispozici verze podporující Thunderbird 3. Poslední změna v kódu, který je licencován jako GPLv3, byla provedena v lednu Sameplace pro svou funkčnost vyžaduje knihovnu xmpp4moz, která byla využita i v původním prototypu ExtBrain Communicatoru. Ukázala se však jako nevhodná, mimo jiné pro svou nefunkčnost v zacílené verzi Thunderbirdu Instantbird Instantbird je samostatná aplikace postavená na Mozilla Application Frameworku. V současnosti je vydána ve verzi 0.2 a je založena na knihovně libpurple, která podporuje velké množství komunkačních protokolů. Kromě XMPP tak například ICQ, IRC, Lotus Sametime a další. Aplikace je velmi příjemně použitelná. Tím, že je samostatná, ale není přímo porovnatelná s aplikací, která bude vyvinuta v rámci této práce Spicebird Spicebird je také samostatná aplikace postavená na Mozilla Application Frameworku a vycházející z Mozilla Thunderbirdu. Je zaměřena na spolupráci uživatelů, kteří ji používají, tvůrci ji označují jako collaboration application. Zjednodušuje práci tím, že poskytuje přístup k webovým aplikacím při zachování pohodlí desktopové aplikace. Interně používá xmpp4moz z projektu Sameplace. Podobně jako Instantbird ji ale není možné přímo srovnat s předmětem vývoje v této práci. 2.5 Ostatní podobná řešení XMPP jako standard je použit i jako základ komunikačních modulů některých známych webových aplikací. Za všechny jsou zde uvedeny dva nejpoužívanější: Google Talk společnosti Google a Facebook Chat společnosti Facebook.

21 KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE GTalk GoogleTalk 1 jeslužbanabízenázdarmavšemuživatelům ovéschránkyspolečnostigoogle (GMail). Služba byla spuštěna v roce 2005 a kromě podpory XMPP používá i knihovnu libjingle pro přenos zvuku a videa. Protože Google Talk používá standardní XMPP, je možné se k serveru připojit libovolným XMPP klientem. Podpora Google Talk bude zabudována i v aplikaci, která bude vyvinuta v rámci této práce Facebook S celosvětovým rozšířením sociální sítě Facebook přišla i potřeba IM komunikace. Facebook, podobně jako Google, sáhl po otevřeném standardizovaném řešení v podobě XMPP. Na Facebook chat je také možné se připojit libovolným klientem, server ale nepodporuje některá rozšíření XMPP protokolu, která jsou běžná u standardních XMPP serverů nebo například u Google Talk. Pomocí rozšíření, které bude výsledkem této práce, se bude možné připojit i na Facebook Chat. 1 bývá také zkracován jako GTalk

22 6 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 3 Analýza a návrh řešení 3.1 XMPP Úvod Jak již bylo uvedeno výše, XMPP je protokol, který je založen čistě na standardizovaných a otevřených technologiích. Základním stavebním kamenem tohoto protokolu je XML 1. Veškerá komunikace mezi entitami propojenými protokolem XMPP probíhá právě pomocí zpráv odpovídajících XML syntaxi. Entity, propojené sítí XMPP se dělí na klient server Na základě tohoto dělení pak v síti probíhají dva typy komunikace: klient server (označované také c2s, z anglického client to server ) server server (označované také s2s, z anglického server to server ) Sít založená na XMPP je decentralizovaná. Každý klient je registrován na jediném serveru a má přiřazen unikátní identifikátor nazývaný JID Jabber ID. JID je strukturován podobně jako ová adresa, tedy ve formátu username@domain.tld. Díky tomuto schématu není nutné zavádět centrální server, který by obsahoval seznam všech registrovaných uživatelů. Protože je možné se přihlásit k XMPP serveru z více míst (respektive více zařízení) najednou, může být k JID ještě přidán identifikátor tzv. resource, který jednoznačně určuje jednotlivé klienty, připojené k serveru pomocí daného JID. Formát takového identifikátoru je pak username@domain.tld/resource. V rámci této analýzy bude zohledňován zejména pohled ze strany klientské aplikace Standardizace a XEPy Jednotlivé standardy jsou definovány IETF v RFC dokumentech. Nejdůležitější pro IM komunikaci jsou: 1 extensible Markup Language

23 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 7 RFC 3290 XMPP: Core [5] RFC 3291 XMPP: Instant Messaging and Presence [6] XMPP je navrženo tak, aby bylo velmi dobře rozšiřitelné, a proto také vzniklo mnoho rozšíření protokolu, která definují chování entit v síti pro různá použití. Tato rozšíření jsou standardizována v dokumentech zvaných XEP (XMPP Extension Protocol). Tyto dokumenty jsou souhrnně uloženy na stránkách xmpp.org, spravovaných XSF (XMPP Software Foundation). Tam je mohou prohlížet a komentovat ostatní vývojáři. Dokumenty XEP se nacházejí v různých stavech; dokončená a schválená rozšíření pak získávají stav final, který zaručuje, že je dokumentace kompletní a standardizovaná. XEP dokumenty jsou číslovány ve formátu XEP-0000 a existuje pět typů: standards track, informational, historical, humorous a procedural. Nejdůležitějším pro implementaci software je typ standards track, který definuje bud protokol na úrovni sít ové komunikace (tedy popisuje samotné rozšíření základního XMPP) nebo specifikuje tzv. conformace requirements (to jsou podmínky, které musí server/klient splnit, aby mohl prohlašovat, že je vyhovující podle daných požadavků) Protokol XMPP je původně založeno na TCP/IP sítích. Vzhledem k jeho verzatilitě ale není problém jej použít i nad jinými technologiemi resp. na jiné sít ové vrstvě, jmenovitě například nad HTTP za využití polling mechanismů 2. Také existuje návrh standardu pro použití XMPP nad technologií WebSockets, která bude umožňovat více oboustranných, plně duplexních kanálů pro komunikaci přes jediný TCP socket. Výchozí port, používaný v TCP/IP pro připojení klient-server je 5222, při spojení typu server-server se používá Strukturně je komunikace pomocí XMPP jeden dlouhý XML dokument. To svým způsobem ztěžuje implementaci, protože je nutné za běhu načítat tzv. nekonečné XML, zároveň je ale možné komunikaci pomocí XML jednoduše validovat. Povinné kódování je UTF-8. Na začátku každé komunikace je nutné otevřít XML dokument a založit kořenový element. Typicky vypadají první data, poslaná klientem takto: <?xml version="1.0" encoding="utf-8"?> <stream:stream xmlns="jabber:client" 2 polling nad HTTP se věnuje XEP-0206 XMPP over BOSH

24 8 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ xmlns:stream=" version="1.0" to="server.tld"> Po úspěšné inicializaci stream elementu, posílají jednotlivé entity skrze tento vytvořený kanál neohraničený počet zpráv, které se v terminologii XMPP nazývají souhrnně stanza. V RFC jsou definovány tři typy zpráv, které je možné poslat v XMPP kanálu: <message /> <presence /> <iq /> Standardní komunikace ve vytvořeném kanále vypadá tedy ve zjednodušení následovně [5]: <stream> <presence> <show/> </presence> <message to= foo > <body/> </message> <iq to= bar > <query/> </iq> </stream> Je důležité zmínit, že zprávy mezi klienty v síti XMPP vždy doručuje server a při komunikaci nevzniká žádný kanál, který by přímo propojoval dvě klientské entity. To je dobré zejména z toho důvodu, že server umí lépe směrovat dané zprávy a zajišt uje také předávání na jiné servery, případně gatewaye pro propojení s jinými komunikačními systémy.

25 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ IM komunikace a online stavy Jak bylo zmíněno výše, během bezchybné komunikace můžou být využity pouze tři definované elementy, nazývané stanzy. Veškerá další rozšíření protokolu jsou pak zapouzdřena do těchto základních stanz Message stanza <message /> stanza je základním stavebním kamenem protokolu. Jde o zprávu, která se předá serveru a obvykle není vyžadováno potvrzení. Tento komunikační typ je určen k rychlému předávání zpráv. Je definováno pět typů zpráv podle důvodu jejich vzniku: normal zpráva podobná u, kdy se neočekává okamžitá odpověd chat zpráva využívaná pro IM, kdy se očekává rychlá výměna zpráv mezi dvěma entitami groupchat zpráva, která je využita pro komunikaci mezi více uživateli najednou, typicky velmi podobné místnosti v IRC headline typ zprávy využitý k informování druhé strany, kdy odpověd není očekávána vůbec error zpráva popisující chybu vzniklou v důsledku přijetí předchozí zprávy Typická zpráva, která prochází sítí v případě uvažované IM komunikace, může vypadat například takto: <message from= juliet@example.com to= romeo@example.net type= chat xml:lang= en > <body>art thou not Romeo, and a Montague?</body> <delay xmlns="urn:xmpp:delay" stamp=" t18:42:03z"/> </message> Většina rozšíření protokolu XMPP pracuje právě s tímto typem stanzy a do těla elementu <message /> vkládá další elementy, které se ve většině případů identifikují svou namespace. Jako příklad lze ve výše uvedené ukázkové zprávě najít element <delay />, který byl vložen podle XEP-0203 Delayed Delivery, a který určuje zpoždění, resp. reálný čas odeslání zprávy.

26 10 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Presence stanza Jednou ze základních vlastností IM sítí je určování, zda je druhá entita přístupná k sít ové komunikaci či nikoliv. K tomuto slouží v XMPP stanza <presence />, pomocí které entita informuje server o svém stavu. Protože taková informace není vždy považována jako veřejná, existuje v XMPP autorizační schéma,kterýmkaždýdanýklienturčuje,kdomůžejehostavvsítividětakdonikoliv.vxmpp terminologii je toto schéma pojmenováno jako presence subscription, v češtině se používá termín autorizace. V tomto schématu jsou definovány čtyři stavy none, from, to, both. Popisují stavy, kdy není mezi dvěma entitami žádná autorizace, existuje autorizace jednosměrná nebo jsou entity vzájemně autorizované. Autorizace je uložena u seznamu kontaktů, který se nazývá roster. Jde vlastně o seznam všech kontaktů spojený s jejich Jabber ID, většinou také zobrazující presence a subscription. Tento seznam je uložen na serveru a každý klient má svůj vlastní, se kterým může operovat. V presence stanze může být uložen i tzv. status klienta, což je krátká textová informace, rozšiřující jeden z definovaných presence stavů. Tyto stavy jsou definovány v RFC a odpovídají již historicky zavedeným stavům pro IM komunikaci, které jsou stejné i ve většině jiných IM systémů. on Entita je on-line away Entita je dočasně pryč chat Entita je k dispozici pro komunikaci xa Entita je pryč na delší dobu dnd Entita nechce být rušena off Entita je off-line Presence stanza může vypadat například takto: <presence xml:lang= en > <show>dnd</show> <status>wooing Juliet</status> </presence>

27 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ IQ stanza <iq /> (z anglického Info/Query) stanza umožňuje využít strukturované komunikace typu požadavek odpověd. Užití je podobné jako například v HTTP protokolu použití GET, POST a PUT. Existují 4 typy IQ stanz: get odesílatel požaduje nějaké informace či provedení nějaké akce. Tento typ zprávy je podobný HTTP GET. set odesílatel poskytuje informace, případně žádá o provedení nějaké akce. Tento typ zprávy je podobný HTTP POST nebo PUT. result odesílatel odpovídá na get zprávu odesláním požadovaných informací nebo potvrzuje provedení akce žádané pomocí set. error odesílatel upozorňuje protistranu o chybě při zpracování předchozího požadavku. To může být způsobeno chybou oprávnění, chybou systému, atd. Obrázek 3.1: Příklad komunikace pomocí IQ stanz Vyjednání spojení a jeho bezpečnost Existuje několik možností jak zabezpečit XMPP stream. RFC definuje, že obě entity musí použít SASL autentifikaci a měly by použít i TLS šifrování kanálu. Mimo TLS je možné ještě použít SSL anebo posílat komunikaci nezašifrovanou. Poslední z možností je nejméně náročná

28 12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ na použitý hardware, je ale zároveň nejméně bezpečná, protože je možné zasílané zprávy na síti odposlechnout. K zajištění autenticity obou stran komunikace se používá profil SASL, specifická revize pro XMPP. SASL je zkratkou pro Simple Authentication and Security Layer a definuje způsob, jakým účastníci komunikace sestavují spojení tak, aby bylo důvěryhodné Průběh SASL Po úspěšném otevření streamu musí server odeslat seznam povolených mechanismů autentifikace. Společně s tímto seznamem posílá i informaci zda podporuje případně vyžaduje použití TLS během následujícího spojení. Pokud je TLS požadováno, zahájí se komunikace na socketu pomocí TLS. Po získání seznamu podporovaných mechanismů, případně po přepnutí socketu na TLS, klient vybírá, který autentifikační mechanismus vybere. V současné době jsou nejpoužívanějšími (rozhodně ale ne jedinými) mechanismy: DIGEST-MD5 PLAIN Při neúspěšné autentifikaci server obvykle ukončuje spojení. Po úspěšné autentifikaci druhé strany se otevírá nový stream, který již může být považován za ověřený. Dalším krokem k úspěšnému sestavení spojení je tzv. bind, kdy klient žádá server o přiřazení Jabber ID k danému resource. Pokud proběhne tento krok v pořádku, může klient požádat o vytvoření Jabber session (není vždy nutné). Poté je spojení kompletní a může se přistoupit k posílání XMPP stanz. V případě, že se některá ze stran komunikace pokusí o zaslání dat ještě před sestavením ověřené komunikace, kanál musí být serverem uzavřen a je oznámena chyba <not-authorized/>. Celý proces sestavování komunikace je dobře popsaný grafem na obrázku A.1 v příloze PLAIN autentifikace PLAIN autentifikace je nejjednodušší způsob, jak provést ověření uživatele. Klient zasílá JID, uživatelské jméno a heslo v nezašifrované podobě, pouze zakódované jako base64 ve formátu username@server<0>username<0>secret.

29 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 13 Zaslaná data můžou vypadat jako 3 : <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="plain"> </auth> ag2udmficnvjzwt3az11hawruy29ra2hv3nphyfj3d2vrag9mznf3btk4mq== Server odpovídá na daný token elementy <success /> nebo <failure /> a v případě chyby uzavírá spojení DIGEST-MD5 autentifikace DIGEST-MD5 je založena na ověřování stylem challenge response. To znamená, že klientská strana nikdy neposílá ověřovací data bez vyžádání serverem. To jednoznačně přispívá k bezpečnosti celého způsobu ověřování. Pokud tedy zvolí klient jako mechanismus DIGEST-MD5, musí čekat, než si server vyžádá autorizační údaje zasláním <challenge /> zprávy, tedy výzvy k ověření. V této výzvě jsou pomocí base64 zakódována data, která klient musí přečíst a na jejich základě vytvořit odpověd, která potvrdí, že tento klient zná heslo k danému uživatelskému jménu. <auth xmlns= urn:ietf:params:xml:ns:xmpp-sasl mechanism= DIGEST-MD5 /> Server odpoví výzvou, která obsahuje řetězec s páry atribut-hodnota oddělenými čárkou, například: <challenge xmlns= urn:ietf:params:xml:ns:xmpp-sasl > cmvhbg09imnoyxquzmfjzwjvb2suy29tiixub25jzt0ioezfrujdmzk4rd c1rtffqumwotrenkneqzkzrde3mzgilhfvcd0iyxv0acisy2hhcnnldd11 dgytocxhbgdvcml0ag09bwq1lxnlc3m= </challenge> dekódováno jako: realm="chat.facebook.com",nonce="8feebc398d75e1eac094d6cdc93d1738", qop="auth",charset=utf-8,algorithm=md5-sess 3 při použití SASL není dovoleno posílat tzv. whitespace znaky; zde jsou použity pouze pro zpřehlednění ukázky

30 14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Na základě získaných údajů může klient sestavit odpověd. Jak napovídá název autentifikace, využívá hashovací algoritmus MD5. Klient přeposílá většinu hodnot původní výzvy, přidává ale zejména atributy username a response, kterými dokazuje znalost hesla. Výhodou je, že heslo z response nelze zpětně získat. Response se sestavuje takto: 1. Sestaví se řetězec username:realm:password, který nazveme A 2. Vypočítá se 16-oktetový MD5 hash z řetězce A, který označíme B 3. Vytvoří se řetězec B:nonce:cnonce:authzid, který nazveme A1 4. Vytvoří se řetězec AUTHENTICATE:digest-uri, který nazveme A2 5. A1 a A2 se zahashují pomocí MD5 jako hexadecimální řetězce a výsledky nazveme H1 a H2 6. Řetězec H1:nonce:nc:cnonce:qop:H2 se zahashuje pomocí MD5 a jeho 32B hexadecimální výsledek je hodnotou response Výsledný řetězec, který klient vrací serveru, může vypadat například takto: username="user1",realm="chat.facebook.com",nonce="8feebc398d75e1eac094", cnonce="8feebc398d75e1eac094",nc= ,qop=auth,digest-uri="xmpp/localhost", response=3b395a5824d41a1bd0228a709e8fd78e,charset=utf-8 A konečný element poslaný do XMPP kanálu tedy bude: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> dxnlcm5hbwu9invzzxixiixyzwfsbt0iy2hhdc5mywnlym9vay5jb20ilg 5vbmNlPSI4RkVFQkMzOThENzVFMUVBQzA5NCIsY25vbmNlPSI4RkVFQkMz OThENzVFMUVBQzA5NCIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LX VyaT0ieG1wcC9sb2NhbGhvc3QiLHJlc3BvbnNlPTNiMzk1YTU4MjRkNDFh MWJkMDIyOGE3MDllOGZkNzhlLGNoYXJzZXQ9dXRmLTg= </response> Před samotným dokončením autorizačního mechanismu posílá server ještě jednu <challenge />, na kterou klient odpovídá prázdným <response /> elementem. Poté je úspěch potvrzen přijetím <success /> elementu. V případě chyby je vrácen element <failure /> a spojení je ukončeno 4. 4 V tomto popisu nejsou uvedeny namespace jednotlivých elementů, které musí byt v reálné komunikaci přítomny

31 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Mozilla Application Framework Mozilla Application Framework(původně také označovaný jako XPFE, tj. Cross Platform Front End) je rodina multiplatformních frameworků (resp. komponent), ze kterých se skládají Mozilla aplikace JavaScript Většina kódu Mozilla aplikací je napsána v JavaScriptu. JavaScript je dynamicky typovaný, objektově orientovaný skriptovací jazyk, jeho přístup k objektům je ale od klasických jazyků typu Java odlišný používá totiž prototypování. V jazycích založených na prototypech existují dva způsoby, jak vytvořit objekt (narozdíl od jediné možnosti u klasických class-based jazyků, kde je vždy použit konstruktor). Objekt může být vytvořen takzvaně ex nihilo (latinsky z ničeho) nebo pomocí klonování existujícího objektu (resp. jeho prototypu). Klonováním pak vzniká objekt, který je stejný jako zdrojový. I když takovýto model nepoužívá přímo dědičnost tak, jak je použita v klasických class-based jazycích, je možné tento přístup dobře simulovat (i když ne vždy je to vhodné). JavaScript je velmi vyspělý jazyk a mezi další zajímavé vlastnosti patří anonymní funkce, vnořené funkce, uzávěry, funkce s proměnným počtem argumentů a další Komponenty frameworku Mezi nejdůležitější komponenty Mozilla Application Frameworku patří bezesporu Gecko neboli layout engine, podporující HTML, CSS, JavaScript, XUL a další. Tento vykreslovací engine je základem většiny Mozilla aplikací, z nichž jistě nejznámější je Mozilla Firefox. Komponentou, použitou pro uživatelské rozhraní v Mozilla Application Frameworku, je XUL. XUL je zkratka pro XML User Interface Language a jde o jazyk založený na XML popisující uživatelské rozhraní. Zahrnuje podporu pro CSS a JavaScript a je závislé na vykreslovacím engine Gecko. Definuje obecně velké množství ovládacích prvků, které se mohou na jiných platformách vykreslovat různě a přitom mít stejnou definici v XUL. S XUL souvisí i jazyk XBL, který umožňuje definovat vlastní ovládací prvky, které budou použity v XUL. Další důležitou částí Mozilla Aplication Frameworku je Necko. Jedná se o knihovnu poskytující API pro podporu sít ových aplikací pracující na různých vrstvách OSI modelu. XPCOM je komponentový model, pomocí něhož Mozilla Application Framework poskytuje

32 16 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ multiplatformní správu komponent, abstrakci souborů, předávání objektů a správu paměti [8]. Umožňuje využít téměř všechny vlastnosti ostatních částí frameworku využít ze skriptů jakékoliv Mozilla aplikace. Komponenty XPCOM mohou být mimo C++ implementovány i v JavaScriptu, Javě nebo Pythonu. XPCOM používá dialekt IDL (Interface Definition Language), nazývaný XPIDL. XPCOM samo o sobě nabízí základní komponenty jako správu paměti, základní datové struktury (řetězce, pole a další). Většina komponent ale pochází z jiných částí frameworku, zejména z komponent Gecko a Necko. XPConnect je technologie, která propojuje JavaScript na úrovni interface a XPCOM komponenty v rámci Mozilla aplikace, jak ukazuje obrázek 3.2. Obrázek 3.2: Mozilla Application Framework XPConnect, zdroj: [3] XPInstall je technologie, která umožňuje uživatelům i vývojářům Mozilla aplikace jednoduše instalovat, rozšiřovat či aktualizovat. Balík, ve kterém je software distribuován, je nazýván XPI (Cross Platform Installation archive) a je to ZIP soubor obsahující soubory v definované struktuře (více v kapitole ).

33 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 17 Obrázek 3.3: Instalace XPI balíku do Mozilla aplikace Vytváření rozšíření Mozilla aplikace Tato kapitola práce se bude zabývat tím, jak lze vytvořit add-on (resp. rozšíření) pro Mozilla aplikaci, konkrétně Mozilla Thunderbird. Sada souborů XUL, JavaScript, CSS a jiných se souhrnně nazývá balík (package). Do Mozilla aplikací je možné tyto balíky instalovat pomocí XPInstall a jejich obsah referencovat pomocí Chrome URL. Instalovatelný balík se musí řídit pravidly, která definují, jakou má takové rozšíření mít strukturu, aby bylo do aplikace instalovatelné. Balík může obsahovat mimo rozšíření aplikace i definic změny vzhledu, případně více rozšíření najednou. Dále v této práci budou popsány hlavní vlastnosti balíku obsahujícího pouze jedno rozšíření Mozilla aplikace Chrome URL Výraz chrome má v Mozilla Application Frameworku více významů; v této práci bude ale převládat ten, který popisuje chrome:// URL. Taková URL se využívá v Mozilla aplikacích k definici místa, kde se nachází určitý soubor. Zapisují se podobně jako dobře známé HTTP URL, ale referencují soubory, které jsou registrované v tzv. chrome registry. To umožňuje mít soubory fyzicky umístěné kdekoliv a přitom je referencovat vždy stejným chrome URL. Typická chrome URL vypadá má formát chrome://<package name>/<part>/<file.xul>, kde <package name> je název balíku, <part> je název jeho části (může být content, skin nebo locale) a poslední částí je přímo jméno soubor (case-insensitive).

34 18 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Chrome manifest a struktura add-onu Chrome manifest popisuje daný balík a mapuje fyzické umístění souboru na Chrome URL. Navíc definuje jednotlivým adresářům, resp. souborům, jak s nimi má aplikace zacházet, tedy jestli se jedná o spustitelný obsah, definici vzhledu, lokalizaci a podobně. Také je možné pomocí direktivy overlay slučovat soubory se soubory z jiných balíků. Tato funkčnost je velmi důležitá, protože umožňuje sloučit existující uživatelské rozhraní s nově přidaným. content addon.chrome chrome/content/ skin addon.chrome classic chrome/skin/classic/ overlay chrome://messenger/content/messenger.xul \\ chrome://addon.chrome/content/myownoverlay.xul Instalovatelný balík musí také dodržovat předepsanou strukturu souborů, aby byl funkční. Důležitý je RDF soubor, který definuje mimo jiné jméno, verzi, identifikaci balíku a zacílenou Mozilla aplikaci (resp. aplikace). Typické rozšíření pro Mozilla aplikaci může mít strukturu, která je uvedena v tabulce 3.1. /install.rdf Instalační manifest s popisem balíku /chrome.manifest Chrome manifest /chrome/content/* Hlavní obsah balíku /chrome/skin/* Definice vzhledu UI /defaults/preferences/*.js Výchozí nastavení preferences Tabulka 3.1: Struktura instalovatelného balíku rozšíření

35 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ ExtBrain Communicator V této práci bude navržena a implementována knihovna pro komunikaci v XMPP tak, aby byla optimalizována pro Mozilla Application Framework a zejména tak, aby poskytovala dobře použitelné rozhraní pro přístup ke XMPP kanálu, které bude přístupné jiným částem projektu ExtBrain. Další částí bude implementace klienta, který umožní komunikovat přes XMPP a pracovat s adresáři poštovního klienta Thunderbird. Jak již bylo řečeno, rozšíření, které vznikne v rámci této práce, vznikne částečně z již existujícho ExtBrain Communicatoru. Tento nefunguje v nové verzi Mozilla Thunderbid, přesto práce bude vycházet z již zavedených konceptů grafického rozhraní; bude ale přidávat nové vlastnosti, které ve starší verzi Thunderbirdu nebyly k dispozici XMPP knihovna Knihovna bude potřebovat přímý přístup k socketu, jenž bude zprostředkován JavaScriptu XPCOM komponentou frameworku Necko. Obrázek 3.4: Návrh třídy XMPPSocket Protože se XMPPSocket bude zabývat pouze připojením ke XMPP serveru, bude objekt naslouchající příchozím datům na socketu data rovnou převádět na DOM reprezentaci daného XML, které bude předáváno dále.

36 20 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Příchozí XML bude analyzováno komponentou nsidomparser, která vrací příslušnou reprezentaci v DOM. DOM, který bude výstupem z objektu XMPPSocket (obrázek 3.4), bude předáván třídě objektu XMPP(obrázek 3.5). Ten bude zastřešovat veškerou základní komunikaci s XMPP serverem. Bude implementovat: Otevření spojení a jeho zabezpečení Autentifikaci vůči serveru (podpora PLAIN a DIGEST-MD5 metod) Binding JID Otevření jabber session Odesílání dat Přijímání dat a vznik událostí na jejich základě Řádné ukončení spojení Obrázek 3.5: Návrh třídy XMPP Zpracování událostí vzniklých při příjmu dat bude řešit objekt, který si zaregistruje daný listener. V tomto případě to bude objekt Jabber (obrázek 3.6), který bude tvořit most mezi událostmi přijatými z grafického rozhraní a z XMPP kanálu. Diagram tříd je k nahlédnutí na obrázku A.3 v příloze.

37 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 21 Obrázek 3.6: Návrh třídy Jabber Řešení více souběžných XMPP spojení Jelikož mezi požadavky na vyvíjený add-on je možnost spuštění více spojení najedou, bude implementován kontejner, ve kterém budou uložena spojení (resp. objekty Jabber), S těmi bude možné hromadně nebo jednotlivě manipulovat. Každý klient s platným XMPP spojením musí mít unikátní Jabber ID, bude možné jednotlivá spojení podle Jabber ID identifikovat. Bude implementován objekt, který bude informace o JID shromažd ovat. Obrázek 3.7: Návrh třídy Connections

38 22 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Kontakty z adresářů a z rosteru Každý XMPP účet má na serveru definován svůj vlastní roster, tedy seznam všech kontaktů. V běžných klientech se po spojení se serverem tento roster zobrazí jako seznam kontaktů současně s informací o online dostupnosti daného kontaktu. Mozilla Thunderbird má svůj vlastní systém adresářů, ve kterých ukládá kontaktní informace, a protože se jedná o poštovní klient, jde zejména o ové adresy. Adresářů může být v Thunderbirdu více než jeden, vyhledávat lze ale vždy jen v jednom vybraném. Proto bude ExtBrain Communicator rozšíření zobrazovat sloučeně kontakty ze všech v nastavení vybraných adresářů a z rosterů všech připojených účtů a umožňovat v nich efektivně vyhledávat. Bude nutné implementovat třídu Contact, která bude schopna zobrazovat informace ze svého rodičovského adresáře, a zároveň se slučovat s kontakty v rosteru podle Jabber ID. Bude upraven formulář na úpravu (resp. přidání) kontaktu a v něm bude zpřístupněna možnost definovat omezený počet Jabber ID, se kterými se tento kontakt sloučí. Obrázek 3.8: Návrh třídy Contact

39 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Uživatelské rozhraní Uživatelské rozhraní bude vycházet z původního prototypu ExtBrain Communicatoru, tedy v levém dolním rohu aplikace bude umístěn seznam kontaktů společně s dalšími ovládacími prvky spojení. Návrh vzhledu je na obrázku 3.9. Obrázek 3.9: Uživatelské rozhraní hlavního okna Po příchodu nové zprávy nebo po uživatelově žádosti se otevře konverzační okno v nové záložce poštovního klienta (obrázek 3.10), kde budou jednotlivé konverzace odděleny systémovými záložkami. Oknu bude dominovat textové pole s konverzací, bude zobrazovat informace o příjemci a bude umožňovat také výběr Jabber ID odesílatele i příjemce.

40 24 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 3.10: Uživatelské rozhraní záložky s konverzací K nastavení účtů bude vytvořen formulář (obrázek 3.11), který bude umístěn do hlavní nabídky Tools aplikace. Po vyvolání se zobrazí okno, které bude umožňovat úpravu, mazání a zakládání jednotlivých jabber účtů. Zároveň také bude k dispozici seznam dostupných adresářů, které se budou používat k zobrazení v seznamu kontaktů tohoto rozšíření. Obrázek 3.11: Uživatelské rozhraní nastavení

41 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Vývojové prostředí a použité nástroje Vývoj rozšíření proběhne za pomoci integrovaného vývojového prostředí (IVP, resp. IDE 5 ) NetBeans [10] a jeho plug-inu foxbeans [12]. Ten umožňuje jednoduše konfigurovat, vyvíjet a sestavovat projekt jako rozšíření pro Mozilla aplikace. Pro testování knihovny pro práci s XMPP byl použit open-source jabber server ejabberd verze [4]. Pro debugování na sít ové úrovni byl použit Network Protocol Analyzer Wireshark verze [13]. Pro vývoj a testování v rámci Thunderbirdu byl použit JavaScript Debugger Venkman, klient pro SQLite databáze SQLite Manager a prohlížeč aktivního DOM DOM Inspector. Pro ladění vzhledu aplikace byl použit XUL designer XULExplorer verze 1.0a1, který umožňuje zadané XUL okamžitě prohlížet. Pro průběžné testování klientem na druhé straně spojení byl použit Mac OS X klient Adium verze [1]. Pro verzování byl použit nejdříve systém SubVersion, poté byl projekt převeden na Mercurial, výchozí VCS 6 Mozilla aplikací. 5 Integrated Development Envrironment 6 Version Control System

42 26 KAPITOLA 4. REALIZACE 4 Realizace V této kapitole budou popsány méně standardní části implementace společně s problémy, které při vývoji vyvstaly. 4.1 Knihovna XMPP Socket Implementace XMPP knihovny používá XPCOM komponenty Mozilla Application Frameworku. K získání přístupu k socketu je použita komponenta nsiprotocolproxyservice, která poskytuje přístup k fyzickému socketu pomocí streamů. Pro příchozí data je použit řetěz komponent (resp. jejich rozhraní) nsiinputstreampump, nsiscriptableinputstream a nsiscriptableunicodeconverter. Ten umožňuje číst textová data ze socketu převedená přímo do požadovaného kódování (dle RFC dokumentu je to UTF- 8). Zápis do socketu je prováděn přímo pomocí interface nsiconverteroutputstream, který data konvertuje do zvoleného kódování. Je použito asynchronní čtení ze socketu. Objekt, který zpracovává data, musí implementovat nsisimplestreamlistener, tedy metody: onstartrequest onstoprequest ondataavailable v ní. Třída Socket tyto metody implementuje, takže asynchronní volání jsou zpracovávána přímo this._inputpump = ].createinstance(ci.nsiinputstreampump); this._inputstream = this._transport.openinputstream(0,0,0); this._inputpump.init(this._inputstream, -1, -1, 0, 0, false); this._inputpump.asyncread(this, null); this._outputstream = this._transport.openoutputstream(0,0,0); this._output = ]

43 KAPITOLA 4. REALIZACE 27.createInstance(Ci.nsIConverterOutputStream); this._output.init(this._outputstream, UTF-8, 0,?.charCodeAt(0)); Analýza XML Parser Jak bylo uvedeno dříve, třída Socket zpracovává také přijaté XML a vytváří jeho reprezentaci v DOM, kterou předává dalším komponentám ke zpracování. Jako parser byla použita komponenta DOMParser. Nevýhodou DOMParseru je, že při chybě nepracuje s výjimkami, ale vrací chybu, která není zachytitelná klasickou try catch konstrukcí. Metodou parsefromstring je tedy možné zpracovat pouze validní XML a není možné jednoduchým způsobem zjistit, zda byla operace provedena úspěšně či nikoliv. Protože je XMPP stream takzvaně nekonečné XML a často používá namespace, nejsou části přijaté na straně socketu validním XML. Při sestavování spojení může dojít například k přijetí následující posloupnosti paketů: #1: <?xml version="1.0"?> <stream:stream xmlns="jabber:client" xmlns:stream=" version="1.0" to="localhost"> #2: <stream:features xmlns:stream=" <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>plain</mechanism> <mechanism>digest-md5</mechanism> </mechanisms> </stream:features> #3: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/> Z uvedených příkladů můžou být DOMParserem jako validní vyhodnocena pouze data číslo 3. První přijatý text není platným XML, protože element <stream:stream /> není platně uzavřen (což je ale základní vlastností neskončené komunikace pomocí XMPP). Druhý přijatý text také není platný, protože element s lokálním názvem <features /> nemá nad sebou obalový element <stream />.

44 28 KAPITOLA 4. REALIZACE Problém je v kódu vyřešen tak, že se kontroluje, zda jde o začátek XMPP streamu, a následně je pak každý přijatý element zabalen do elementu <stream:stream />. To způsobí, že veškeré elementy přijaté v kanálu jsou platným XML. Následuje příklad zpracovaného elementu číslo 2, který je již platným XML. <stream:stream xmlns="jabber:client" version="1.0" xml:lang="en" xmlns:stream=" <stream:features xmlns:stream=" <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>plain</mechanism> <mechanism>digest-md5</mechanism> </mechanisms> </stream:features> </stream:stream> Fragmentace Dalším problémem při zpracování dat přijatých v Socketu je fragmentace příchozího XML. Ta se projevuje zejména při přijímání většího objemu dat, zejména při příjmu binárních dat (v kanále XMPP kódovaných pomocí base64) jako jsou například avatary uživatelů. Pro tento případ je implementována funkce, která kontroluje, zda jsou XML data řádně zakončená. #1: <message from="jid@server" to="jid2@server"> <event xmlns=" <items node="urn:xmpp:avatar:data"> <item id="96dd92efb8c9cbbd62100add0dacbd62b7e0b6af"> <data xmlns="urn:xmpp:avatar:data">ivborw0kggoaa... base64 data... #2: 5m6XSXU+sAAAAASUVORK5CYII= </data> </item> </items> </event> </message>

45 KAPITOLA 4. REALIZACE 29 Pokud se zjistí, že daná data nejsou řádně zakončena, uloží danou část do mezipaměti a při přijetí další části spojí obě dohromady a provede kontrolu znovu. Tím je zajištěno, že výsledné XML, které je předáno parseru, je platné Udržování spojení Protože XMPP jako protokol nemá informaci o délce timeoutu TCP/IP spojení, zavedl se takzvaný whitespace ping, kdy server či klient v určitých intervalech zapíší do kanálu znak mezery, aby nedošlo k uzavření spojení. XML validaci sice znak mezery nebrání, ale nejde o systémové řešení. Proto bylo zavedeno rozšíření XEP-0199, které definuje správný XMPP Ping. Ping je definován jako IQ stanza obsahující element ping s namespace urn:xmpp:ping. Pokud protistrana neimplementuje tento XEP, standardně odpoví chybovou hláškou <service-unavailable />. To však má jako vedlejší účinek to, že se oživí dané TCP/IP spojení. Při testování vyvíjené aplikace byla zjištěna nejmenší hodnota timeoutu u služby serveru jabber.org a podle ní byla nastavena frekvence posílání v pětiminutových intervalech Zpracování přijatého DOM Jak bylo popsáno dříve, výstupem ze třídy Socket je DOM reprezentace elementů (případně elementu) přijatých ze serveru. Pro každý z těchto elementů je pak volána metoda ondataavailable třídy XMPP. Ta na základě jména a namespace elementu rozhodne, jak bude program na přijatá data reagovat. Samotný protokol se může nacházet v několika různých stavech a podle toho také očekávat přijetí různých dat. Toto je popsáno v objektu protocolhandler, který obsahuje logiku zpracování vzniklé události. Jeho struktura vypadá takto: protocolhandler: { stream-opened : { features: function(extxmpp, data) {... } },... connected : { message: function(extxmpp, data) {

46 30 KAPITOLA 4. REALIZACE } }... }, presence: function(extxmpp, data) {... }, iq: function(extxmpp, data) {... } Na ukázce je vidět, že ve stavu stream-opened je očekáván element features. Dále pak, že pokud je spojení aktivní (stav connected), jsou očekávány elementy message, presence nebo iq. Pokud je přijat nějaký element, ke kterému není nalezen příslušný handler, je vyvolána výjimka. Třída XMPP zastřešuje základní práci s protokolem a poskytuje metody pro čtení a zápis do vzniklého kanálu. Pro čtení jsou zde implementovány události, které vznikají jednak na základě změn stavu protokolu (např. connected, disconnected) a také přijatých dat (např. message, presence). Třída poskytuje možnost registrace tzv. listeneru, který je informován o vzniku událostí a jsou mu předávána relevantní data. Listener může implementovat libovolné množství reakcí na události. Příkladem může být následující ukázka kódu, kde jsou zpracovávány události připojení, odpojení a přijetí oznámení o tom, že druhá entita připravuje IM zprávu. listener.prototype = { connected: function(extxmpp, data) {... }, disconnected: function(extxmpp, data) {... } composing: function(extxmpp, data) {... } }

47 KAPITOLA 4. REALIZACE Napojení dalších komponent do XMPP kanálu Návrh knihovny umožňuje jednoduché připojení nových komponent systému do XMPP kanálu. Konkrétní implementace tak může navrhnout svůj vlastní listener, který se připojí k události, kterou chce nový systém sledovat. Pokud by například šlo o analýzu přijatých elementů, je možné využít událost data, která vzniká při příjmu jakéhokoliv XML. Jiný příklad by mohl být monitoring příchozích zpráv, kdy by bylo nutné sledovat událost message. Jednoduchým příkladem by mohl být systém, který by například shromažd oval počet přijatých elementů pro JID user@server. Ten bylo možno implementovat například jako: var connection = connections.getconnectionbyjid( user@server ); var elementscount = 0; connection.xmpp.registerlistenerobject({ data: function() { elementscount++; } }); DIGEST-MD5 Mimo autentifikační metody PLAIN bylo nutné implementovat také metodu DIGEST-MD5. Ta má mezi používanými servery největší podporu právě proto, že je bezpečná 1 i pokud je použita přes nezabezpečené spojení. Metodu popisuje RFC 2831, bohužel je velmi špatně čitelné. Navíc je třeba, aby se v částech algoritmu (popsaném v kapitole ) nepracovalo s obvyklým výstupem MD5 hashovacích algoritmů (tedy s 32 hexadecimálními číslicemi), ale s hrubými daty. Proto byla pro výpočet MD5 použita knihovna napsaná v JavaScriptu a veřejně dostupná pod licencí BSD, která poskytuje jako výstup i nekonvertovaná 128 bitová data. Ta jsou potřeba pro vytvoření odpovědi na DIGEST-MD5 challenge. 4.2 Uživatelské rozhraní Uživatelské rozhraní bylo implementováno dle návrhu v kapitole 3.3.4, které vychází z již existujícího prototypu ExtBrain Communicatoru. Veškerá okna jsou popsána v souborech XUL, z 1 Uměle vykonstruované MD5 kolize sice již byly v roce 2006 prakticky předvedeny, ale v reálném provozu zatím nepředstavují velkou hrozbu.

48 32 KAPITOLA 4. REALIZACE nichž hlavní je contactsbox.xul, který je definován jako overlay hlavního okna poštovního klienta. overlay chrome://messenger/content/messenger.xul \\ chrome://extbrain.thunderbird/content/contactsbox.xul Seznam kontaktů Seznam kontaktů byl pomocí overlaye přes element s id folderpanebox vložen pod seznam účtů a adresářů pošty. Je možné si v něm vybrat, které sloupce budou viditelné a které nikoliv. Obrázek 4.1: Seznam kontaktů Seznam kontaktů je tvořen standardní komponentou XUL tree. Ta umožňuje dynamicky měnit sloupce, které zobrazuje, a zároveň také obsahuje ovládací prvky k řazení podle sloupců. Komponenta tree se definuje jako <tree> <treecols>

49 KAPITOLA 4. REALIZACE 33 <treecol label="column label" /> </treecols> <treechildren> <treeitem> <treerow> <treecell label="item label" /> </treerow>... </treeitem> </treechildren> </tree> Pomocí XUL atributu persist je zajištěno, že si aplikace bude pamatovat i přes své ukončení zobrazené sloupce nebo například hodnotu, podle které byl obsah seznamu řazen. Byla využita již existující implementace nsitreeview, která je popsána v [7]. Seznam všech kontaktů je reprezentován polem contacts uloženým v objektu contactlist. Kontakty, zobrazené v seznamu kontaktů jsou filtrovány z tohoto pole. Je možné vybrat zobrazení pouze on-line uživatelů, je také možné použít textový element nad seznamem kontaktů pro filtrování, resp. hledání mezi zobrazenými kontakty. Filtrace probíhá při volání metody contactlist.search, která do pole contactlist.found zapíše výsledky daného hledání a ty jsou zobrazeny v elementu tree Slučování kontaktů z adresáře a z rosteru V tomto rozšíření existují dva typy kontaktů: Kontakt z adresáře poštovního klienta Kontakt z rosteru jednoho z aktivních účtů Protože poštovní klient Thunderbird umožňuje uživateli mít více adresářů, v nastavení (viz kapitolu 4.2.4) je k dispozici výběr adresářů, ze kterých budou kontakty zobrazeny v seznamu. Každý adresář aplikace Thunderbird je označen vlastním URI, které vypadá například jako moz-abmdbdirectory://abook.mab. Podle tohoto URI se pak v kódu adresář získává za užití rozhraní nsiabmanager.

50 34 KAPITOLA 4. REALIZACE V seznamu kontaktů jsou vždy zobrazeny sloučeně všechny kontakty z vybraných adresářů. Naproti tomu kontakt z rosteru účtu je zobrazen pouze v tu chvíli, kdy je daný účet on-line. Kontakty z adresářů načítá a poskytuje objekt contactsource. Je běžné, že jeden uživatel XMPP sítě vlastní více různých Jabber ID (obvykle na různých serverech), a proto byla implementována funkce slučování kontaktů podle zadaných Jabber ID. Do základního formuláře pro úpravu kontaktu z adresáře byla pomocí overlay vložena další záložka, na které jsou textová pole pro 6 různých Jabber ID. Tyto Jabber ID jsou uloženy ke kontaktu pomocí rozhraní, které poskytuje nsiabcard. K zápisu vlastního atributu ke kontaktu stačí použít metodu setproperty. if (acard instanceof nsiabcard) { for each(var elementid in CardDialogOverlay.customAttributes) { value = adoc.getelementbyid(elementid).value; acard.setproperty(elementid, value); } } Při každém připojení některého z účtů dojde k načtení jeho rosteru ze serveru. Pro každý nový kontakt z rosteru se prochází dosavadní seznam kontaktů a kontroluje se, zda v něm neexistuje kontakt, který by měl již dané Jabber ID definované. Pokud ano, nevytváří se nová položka seznamu, ale k danému kontaktu se napíše, že je dostupný pod daným Jabber ID z daného účtu. Pro rychlé hledání v seznamu je definováno pole jidmap, které obsahuje reference na kontakty podle Jabber ID. Zjednodušeně je proces naznačen v následujícím výtažku z kódu: var tmpcontact = contactlist.jidmap[jid]; if (tmpcontact == undefined) { // Vytvoření nového kontaktu do seznamu... } tmpcontact.addaccount([account, jid]); tmpcontact.addsubscription([account, jid, subscription]);...

51 KAPITOLA 4. REALIZACE Manipulace s kontakty S kontakty je možné manipulovat nejen přes nově vytvořený seznam kontaktů, ale také pomocí standardního rozhraní, které Thunderbird poskytuje. Pokud uživatel kontakt upraví, je nutné tuto změnu propagovat do právě zobrazeného seznamu. Rozhraní nsiabmanager umožňuje přidat listener, který je notifikován o každé změně v adresářích. Jsou definovány tři události: onitemadded onitemremoved onitempropertychanged Protože kontakt v adresáři Thunderbirdu nemá žádný unikátní identifikátor, kterým by jej jedinečně určil, je při zakládání kontaktu do seznamu kontaktů vytvořen a uložen vlastní atribut, nazvaný ExtBrainUniqId. Ten je tvořen MD5 hashem jména kontaktu a časového razítka ve chvíli vytváření. Tento atribut je pouze vytvářen a není nikdy aktualizován a je možné podle něj jednotlivé kontakty identifikovat. Pro obsluhu událostí vznikých v kterémkoliv adresáři byl implementován listener, který na základě změn upravuje zobrazovaný seznam kontaktů. Zejména je nutné hlídat změny v polích obsahujících uživatelem zadaná Jabber ID. Proto byly vytvořeny metody objektu contactsource: mergecardwithrosters unmergecardtoroster Tyto metody se starají o sloučení a případné oddělení kontaktů s daným rosterem. Předpokládejme situaci, kdy uživatel má naplněný seznam kontaktů a jeho jediný XMPP účet je offline. Jeden z kontaktů adresáře má definovány dvě Jabber ID. Pokud se uživatel rozhodne XMPP účet připojit, dojde k následujícímu: 1. Účet se připojí a načte roster 2. Projde se získaný roster pokud dané Jabber ID odpovídá některému z definovaných v kontaktu z adresáře, je toto ID společně s účtem přidáno ke kontaktu pokud dané Jabber ID neexistuje u žádného z kontaktů z adresáře, je zobrazeno v seznamu samostatně

52 36 KAPITOLA 4. REALIZACE Uživatel má nyní účet připojen a pokud upraví tento sloučený kontakt z adresáře tak, že odebere Jabber ID, přes které byl tento kontakt s kontaktem z rosteru sloučen, funkce unmergecardtoroster tuto změnu detekuje. Z kontaktu pak informace o Jabber ID odebere a vytvoří v seznamu nový záznam. Podobná situace nastane při přidání některého z Jabber ID v rosteru k některému kontaktu z adresáře funkce mergecardwithrosters zruší daný roster kontakt a přidá informaci o Jabber ID a účtu ke kontaktu z adresáře Informace o kontaktu Při najetí kurzoru myši na řádek s kontaktem se zobrazí okno, které sumarizuje informace, které jsou o něm dostupné. Toho je dosaženo pomocí XUL elementu tooltip, který je dynamicky přegenerován pokaždé, když se má zobrazit (událost popupshowing). Obrázek 4.2: Box s informacemi o kontaktu Při kliknutí myší pravým tlačítkem je zobrazeno menu, ve kterém může uživatel zahájit konverzaci (pouze pokud má kontakt definované nějaké Jabber ID), měnit autorizace vůči vybranému Jabber ID, zobrazit historii konverzací (viz kapitola 4.2.3), začít psát nový , zahájit hovor na telefonní číslo či zobrazit formulář pro úpravu kontaktu. Pokud uživatel chce upravit data o kontaktu, který není zatím v adresáři, zobrazí se okno pro nový kontakt s předvyplněnými údaji Konverzace Okno s konverzacemi bylo dle návrhu implementováno jako nová záložka poštovního klienta. Ta se otevírá v případě, že přijde nová zpráva nebo uživatel chce započít novou konverzaci. K vyvolání záložky je použito rozhraní Thunderbirdu tabmail. Záložka se pak otevírá následujícím voláním: var tabmail = document.getelementbyid("tabmail");

53 KAPITOLA 4. REALIZACE 37 tabmail.opentab("contenttab", { }); contentpage: "chrome://extbrain.thunderbird/content/consoletab.xul" Obrázek 4.3: Záložka s konverzací Záložka může obsahovat více konverzací; ty jsou pak odděleny systémovými záložkami, kdy každá je nadepsána jménem kontaktu a je na ní zobrazen jeho stav. Pokud má kontakt definováno více různých Jabber ID, jsou tyto zobrazeny v menu, ze kterého může uživatel vybrat, na které JID bude zpráva poslána Obsluha událostí Objekt, který reprezentuje okno s konverzacemi má implementovány handlery pro události přijetí zprávy, změny stavu a zprávy composing (tedy informace o tom, že druhá strana píše zprávu). handlestatuschange

54 38 KAPITOLA 4. REALIZACE handleincomingmessage handlecontactcomposing Při vyvolání některého z handlerů je okno s informacemi příslušně aktualizováno Historie konverzací Historie konverzací je ukládána pomocí objektu chatdb do databáze SQLite, kterou poskytuje rozhraní mozistorageservice. Tabulka má atributy, které jsou uvedeny v tabulce 4.1. Název sloupce Typ sloupce fromjid TEXT tojid TEXT direction TEXT date INTEGER message TEXT Tabulka 4.1: SQLite tabulka historie konverzace Uživatel má možnost zobrazit historii konverzací kliknutím na uživatele v seznamu kontaktů, případně použitím tlačítka přímo v okně s konverzací. Byla převzata i funkčnost z původního prototypu ExtBrain Communicatoru, kdy se jednotlivé zprávy shlukují do konverzací podle zadaného časového intervalu (viz [7], kapitola 4.4) Okno nastavení Okno nastavení (obrázek 4.4) je zobrazeno po výběru volby ExtBrain Settings v menu Tools. V tomto okně má uživatel možnost přidávat a odebírat adresáře, které mají být použity pro zobrazení v seznamu kontaktů, a vytvářet a mazat XMPP účty. Pro vytváření účtů jsou předdefinovány tři šablony, které uživateli usnadní vyplnění údajů a nastavení parametrů spojení. XMPP / Jabber GTalk Facebook

55 KAPITOLA 4. REALIZACE 39 Obrázek 4.4: Modální okno nastavení Šablony jsou definovány v objektu accountplugins, který definuje tranformační funkce pro JID, adresy serveru, portu a zabezpečení spojení. Taková šablona musí vypadat takto: var accountplugins = { jabber: { username:, getusernameprompt: function() { }, getconnecthost: function() { }, getport: function() { }, getsecurity: function() { }, getjid: function() { }, validatejid: function() { } } } Nastavení účtů je uloženo do databáze SQLite podobně jako historie zpráv. Struktura tabulky je uvedena v tabulce 4.2.

56 40 KAPITOLA 4. REALIZACE Název sloupce Typ sloupce jid TEXT connecthost TEXT port INTEGER security INTEGER enabled BOOL Tabulka 4.2: SQLite tabulka nastavení účtů Hesla k jednotlivým účtům jsou bezpečně uložena v systémovém úložišti, ke kterému poskytuje přístup rozhraní nsiloginmanager.

57 KAPITOLA 5. TESTOVÁNÍ 41 5 Testování 5.1 Testovací prostředí K testování byla použita dvě různá prostředí: Microsoft Windows XP SP3, Mozilla Thunderbird Mac OS X , Mozilla Thunderbird Protože je Mozilla Application Framework sám o sobě multiplatformní, všechny jím poskytované funkce musí pracovat stejně na všech platformách. Při testování nebyl zjištěn žádný zásadní rozdíl v chování nebo funkčnosti aplikace ve výše zmíněných testovacích prostředích. Je tedy možné předpokládat, že se aplikace bude chovat stejně i na jiných platformách, než na těch výše uvedených (například v operačním systému Linux). 5.2 XMPP knihovna XMPP knihovna byla testována během vývoje a komunikace se servery byla analyzována pomocí implementované debugovací konzole a také pomocí sít ového analyzátoru Wireshark. Komunikace byla testována zejména s těmito servery, poskytujícími účty zdarma: lokální ejabberd a OpenFire servery jabber.cz jabber.org jabbim.cz talk.google.com chat.facebook.com Komunikace s těmito servery byla monitorována a po dokončení spojení ukládána do souboru, ze kterého byla později analyzována, zda odpovídá standardům a zda nedocházelo během spojení k chybám.

58 42 KAPITOLA 5. TESTOVÁNÍ 5.3 Uživatelské rozhraní Výsledné rozšíření poštovního klienta bylo testováno v součinnosti s vedoucím práce. Nalezené nedostatky byly zaznaménávány a opravovány průběžně během vývoje. Další testování společně s rozšířením doplňku mezi větší množství testerů zajistí vedoucí práce.

59 KAPITOLA 6. ZÁVĚR 43 6 Závěr V rámci této práce byl nastudován protokol XMPP a analyzovány možnosti jeho implementace v prostředí Mozilla Application Frameworku. Následně byla v JavaScriptu implementována knihovna poskytující připojení ke XMPP serverům. Nakonec bylo dle požadavků vedoucího práce implementováno rozšíření aplikace Mozilla Thunderbird, které funguje jako multifunkční XMPP klient. Rozšíření, které vzniklo v této práci, zpřístupňuje kontakty z adresářů Mozilla Thunderbird do jediného seznamu, umožňuje souběžné připojení a komunikaci z více XMPP účtů a slučování kontaktů z nich s kontakty z adresářů poštovní aplikace. Implementuje i podporu jiných komunikačních sítí založených na XMPP jako například Google Talk nebo Facebook Chat. Vzhledem k modulární struktuře implementovaného rozšíření bude možné v budoucnosti využít vzniklou knihovnu i pro implementaci dalších funkčností, například posílání souborů nebo dokonce k sestavování hlasové nebo video komunikace. Do budoucna by také bylo možné vylepšit XMPP knihovnu pracující nyní nad TCP/IP tak, aby pracovala s použitím WebSockets.

60 44 KAPITOLA 6. ZA VE R

61 LITERATURA 45 Literatura [1] ADIUM. Adium, free instant messaging application [online]. [cit ]. [2] BIELAWA, T. State Transitions during the XMPP Client Connection Process [online]. [cit ]. [3] BOSWELL, D. et al. Creating Applications with Mozilla. O Reilly, [4] EJABBERD. ejabberd, the Erlang Jabber/XMPP daemon [online]. [cit ]. [5] IETF. Extensible Messaging and Presence Protocol (XMPP): Core [online]. [cit ]. [6] IETF. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [online]. [cit ]. [7] JIROVEC, D. Integrace Mozilla Thunderbird a XMPP [online]. [cit ]. [8] MOZILLA. Mozilla Application Framework in Detail [online]. [cit ]. [9] NOVOTNÝ, T. ExtBrain - to simplify everyday tasks [online]. [cit ]. [10] ORACLE. NetBeans.org [online]. [11] SAINT-ANDRE, P. SMITH, K. TRONÇON, R. XMPP: The Definitive Guide. O Reilly, [12] TEESOFT. FoxBeans NetBeans Plugin [online]. [cit ]. [13] WIRESHARK FOUNDATION. Wireshark [online]. [cit ].

62 46 LITERATURA

63 PŘÍLOHA A. DIAGRAMY A OBRÁZKY 47 A Diagramy a obrázky Obrázek A.1: Přechody mezi stavy připojování XMPP klienta, zdroj: [2]

64 48 PŘÍLOHA A. DIAGRAMY A OBRÁZKY Obrázek A.2: Návrh tříd pro XMPP knihovnu

65 PŘÍLOHA A. DIAGRAMY A OBRÁZKY 49 Obrázek A.3: Návrh tříd pro práci s kontakty

66 50 PŘÍLOHA B. SEZNAM POUŽITÝCH ZKRATEK B Seznam použitých zkratek IM Instant Messaging XMPP Extensible Messaging and Presence Protocol GUI Graphical User Interface (grafické rozhraní aplikace) XML Extensible Markup Language XUL XML User Interface Language XBL XML Binding Language XPCOM Cross Platform Component Object Model DOM Document Object Model DTD Document Type Definition IDE Integrated Development Environment IVP Integrované Vývojové Prostředí HTML Hypertext Markup Language CSS Cascade Style Sheet JS Javascript VCS Version Control System SSL Secure Sockets Layer TLS Transport Layer Security

67 PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA 51 C Instalační příručka C.1 Požadavky k instalaci K instalaci ExtBrain Communicatoru je nutné mít nainstalován jen Mozilla Thunderbird ve verzi 3.1 a vyšší; optimálně verzi (v době psaní instalační příručky nejnovější verze). C.2 Instalace ExtBrain Communicatoru K instalaci je nutné mít k dispozici balíček extbrain_communicator.xpi. Klikněte v menu Tools na položku Add-ons. V něm vyberte vlevo dole možnost Install a vyberte v adresářové struktuře balíček xpi. Obrázek C.1: Okno Add-ons Thunderbird si vyžádá potvrzení, že opravdu chcete neověřený doplněk nainstalovat - klikněte na Install now.

68 52 PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA Obrázek C.2: Potvrzení instalace Pro dokončení instalace je třeba Thunderbird restartovat. Jednoduše to lze udělat kliknutím na tlačítko Restart Thunderbird. Obrázek C.3: Potvrzení instalace Po restartu aplikace je instalace dokončena.

69 PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA 53 D Uživatelská příručka D.1 Nastavení účtů Po instalaci rozšíření je seznam nastavených účtů prázdný. Pro nastavení vyberte z menu položku Tools a myší klepněte na ExtBrain Settings. Objeví se okno, ve kterém můžete vytvořit nový účet (obrázek D.1). Pro založení nového účtu vyberte položku Account type a klepněte na tlačítko Create new account. Zobrazí se dialog, který vás vyzve k zadání údajů. V případě klasického Jabber účtu to bude vaše JID, například u účtu Facebook Chat jen vaše uživatelské jméno. Obrázek D.1: Okno Nastavení Po potvrzení je vytvořen nový účet a vy můžete vyplnit jeho heslo do políčka Password. Kontakt lze smazat stisknutím tlačítka Delete this account a potvrzením následného dialogu. Pokud nechcete některý z vašich účtů dočasně používat, odškrtněte položku Account enabled. Účet se tak zakáže a nebude se připojovat. Pokud provedete změny v nastavení některého z účtů, který je právě připojen, bude po zavření okna tlačítkem OK tento účet odpojen a znovu připojen.

70 54 PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA D.2 Nastavení zobrazovaných adresářů Aby se v seznamu kontaktů zobrazovaly kontakty z vašich adresářů, je nutné je v okně nastavení (obrázek D.1) ve sloupci Use zaškrtnout. D.3 Připojení účtů Pro připojení všech povolených účtů klikněte na obrázek stavu levým tlačítkem. Zobrazí se menu (obrázek D.2), ve kterém vyberte požadovaný stav a všechny povolené účty se automaticky připojí. Pro odpojení všech připojených účtů v menu zvolte položku Offline. Obrázek D.2: Seznam kontaktů Informace o stavu připojených účtů se zobrazí, podržíte-li chvíli kurzor nad obrázkem stavu (viz obrázek D.3). Obrázek D.3: Informace o stavu účtů Je také možné nastavit stav jednotlivě pro každý z povolených účtů. To můžete provést kliknutím pravým tlačítkem na obrázek stavu účtů (viz obrázek D.4).

71 PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA 55 Obrázek D.4: Nastavení stavu jednotlivých účtů D.4 Započetí konverzace Dvojitý klik na kontakt v seznamu kontaktů může vyvolat tři různé reakce: Pokud má účet definované alespoň jedno Jabber ID a je k dispozici účet, na kterém je k dispozici, otevře se okno pro IM konverzaci. Pokud účet nemá definované žádné Jabber ID, ale je k dispozici jeho ová adresa, je otevřeno okno pro psaní zprávy. Pokud neplatí ani jedna z výše zmíněných podmínek, je otevřeno okno pro editaci kontaktu. Pro započetí IM konverzace je tedy možné využít dvojitý klik na řádek v seznamu kontaktů. Je ale také možné přímo vybrat Jabber ID, kterému chcete zprávu poslat z kontextového menu kontaktu (obrázek D.5). Obrázek D.5: Kontextové menu kontaktu Po kliknutí se otevře záložka s oknem IM konverzace (obrázek D.6). Odeslání zprávy provedete bud stisknutím klávesy Enter nebo kliknutím na tlačítko Send

72 56 PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA Obrázek D.6: Záložka s konverzací D.5 Úprava kontaktu Položky karty adresáře vybraného kontaktu upravíte kliknutím na položku Edit... v kontextovém menu daného kontaktu. Pokud chcete pracovat s autorizacemi, vyberte v kontextovém menu položku Subscriptions. Posílat, resp. odebírat autorizace můžete pro všechny Jabber ID, které má daný kontakt definované, ze všech vašich připojených účtů. D.6 Sloučení kontaktu z rosteru s kontaktem z adresáře Pokud chcete, aby jeden kontakt z adresáře do sebe slučoval více různých Jabber ID, otevřte úpravu kontaktu, vyberte záložku ExtBrain JID s a vyplňte požadovaná Jabber ID do zobrazených polí. Po uložení kontaktu se tento kontakt automaticky sloučí s kontakty v rosteru, která mají zadané Jabber ID. Pokud Jabber ID z kontaktu odeberete, jednotlivá Jabber ID budou automaticky zobrazena jako kontakty z rosteru.

73 PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA 57 Obrázek D.7: Okno pro úpravu přiřazených JID D.7 Zobrazení historie konverzace Pro zobrazení historie konverzace vyberte položku kontextového menu kontaktu Show chats history... nebo klikněte v otevřené IM záložce na tlačítko Show history. Bude zobrazeno okno s historií všech konverzací s daným kontaktem (resp. všemi jeho přiřazenými Jabber ID). Konverzaci zobrazíte kliknutím na řádek v seznamu konverzací. Konverzaci je možné smazat kliknutím pravým tlačítkem a výběrem položky Delete.