BAKALÁŘSKÁ PRÁCE. Systém pro registraci a správu DNS domén druhého řádu Jan Baroš. Vedoucí práce: Mgr. Jan Outrata, Ph.D.

Rozměr: px
Začít zobrazení ze stránky:

Download "BAKALÁŘSKÁ PRÁCE. Systém pro registraci a správu DNS domén druhého řádu. 2015 Jan Baroš. Vedoucí práce: Mgr. Jan Outrata, Ph.D."

Transkript

1 BAKALÁŘSKÁ PRÁCE Systém pro registraci a správu DNS domén druhého řádu 2015 Jan Baroš Vedoucí práce: Mgr. Jan Outrata, Ph.D. Studijní obor: Aplikovaná informatika, kombinovaná forma

2 Bibliografické údaje Autor: Název práce: Typ práce: Pracoviště: Rok obhajoby: 2015 Studijní obor: Vedoucí práce: Počet stran: 47 Přílohy: Jazyk práce: Jan Baroš Systém pro registraci a správu DNS domén druhého řádu bakalářská práce Katedra informatiky, Přírodovědecká fakulta, Univerzita Palackého v Olomouci Aplikovaná informatika, kombinovaná forma Mgr. Jan Outrata, Ph.D. 1 CD/DVD český Bibliograhic info Author: Title: Thesis type: Department: Year of defense: 2015 Study field: Supervisor: Page count: 47 Supplements: Thesis language: Jan Baroš System of second level DNS domain registration and management bachelor thesis Department of Computer Science, Faculty of Science, Palacký University Olomouc Applied Computer Science, combined form Mgr. Jan Outrata, Ph.D. 1 CD/DVD Czech

3 Anotace Cílem práce bylo vytvořit program pro usnadnění úkonů spojených s registrací a správou DNS domén 2. řádu. Program byl vytvořen jako řešení pro registrátora ProfiHOSTING s.r.o. pokrývající potřeby společnosti a jejich zákazníků, včetně spojených administrativních úkonů. Synopsis The main goal of the thesis was to create a program to make registration and management of second level domain names more feasible. The program has been created as a solution for registrar ProfiHOSTING s.r.o. while covering the needs of the company and their customers, including related administrative tasks. Klíčová slova: doména, doménové jméno, tld, registr, registrátor, technický správce, DNS server, skupina DNS serverů Keywords: domain, domain name, tld, registry, registrar, technical contact, DNS server, DNS server group

4 Rád bych poděkoval za vedení mé práce panu Mgr. Janu Outratovi, Ph.D, za podnětné připomínky a doporučení, které měly na samotnou práci velký vliv. Dále děkuji zástupcům společnosti ProfiHOSTING s.r.o., paní Ivetě Brixové a panu Tomášovi Vrbickému za laskavé poskytnutí součinnosti, přístupu k dokumentačním materiálům, přístupů na testovací servery registrů a virtualizovaného serveru pro testovací provoz programu. V neposlední řadě děkuji své nastávající manželce Mgr. Gabriele Večerkové za neskutečnou trpělivost a podporu i v těch nejkritičtějších chvílích. Místopřísežně prohlašuji, že jsem celou práci včetně příloh vypracoval samostatně a za použití pouze zdrojů citovaných v textu práce a uvedených v seznamu literatury. datum odevzdání práce podpis autora

5 Obsah 1 Úvod Motivace Představení profilu společnosti ProfiHOSTING s.r.o Úvod do problematiky domén Doména prvního a druhého řádu Princip delegace Životní cyklus domény Podpora IDN Popis elektronické komunikace s registry CZNIC a EURid Autentizace a zabezpečení Správa kontaktů Správa kontaktů v registru CZNIC Správa kontaktů v registru EURid Správa domén Správa domén v registru CZNIC Správa domén v registru EURid Správa skupin DNS serverů Správa skupin DNS serverů v registru CZNIC Správa skupin DNS serverů v registru EURid Poskytované údaje o účtu registrátora Zprávy zasílané registrem registrátorovi Implementace Použité technologie a programy Návrh architektury programu Popis implementace komunikace s registry Popis jednotlivých fasád ValueObject a CommandObject Fasáda DomainContactFacade Fasáda DomainNSSetFacade Fasáda DomainNameFacade Fasáda InvoicingOrderFacade Fasáda InvoicingPricelistFacade Schéma databáze a komunikace s databází Zabezpečení programu Popis webového rozhraní programu Testování programu Instalace programu a požadavky na server Závěr 44 5

6 Conclusions 45 A Obsah přiloženého CD/DVD 46 Bibliografie 47 6

7 1 Úvod 1.1 Motivace Porozumění problematice registrace a správy DNS domén druhé úrovně je dnes stále vlastní jen odborné veřejnosti. Velká část vlastníků webových stránek má problém pochopit, proč je jim účtován registrační poplatek domény navíc ke službám webhostingu. Navzdory snaze správců registrů popularizovat toto téma, např. v podobě TV spotů Jak na internet provozovatele registru CZNIC, se situace nelepší. Stále je patrná velká režie přenesená na zaměstnance registrátorů spojená s jednoduchými administrativními úkony a velmi nízká samostatnost vlastníků DNS domén. Část viny nese složitost problematiky samotné, druhým viníkem jsou příliš složité nebo z hlediska uživatelského rozhraní překomplikované programy poskytované samotnými registrátory. Další kapitolou jsou pak nástroje, které mají zaměstnanci registrátorů k dispozici pro zajištění správy DNS domén. Pokud společnost registrátora nezainvestovala do vlastního vývoje administračního systému, musí své procesy přizpůsobit nástrojům poskytovaným přímo samotnými registry. Je zřejmé, že v takovém případě se nutně musí část režie s administrativními úkony přenést na vlastníky domén a komunikace mezi nimi a registrátorem se takto značně ztíží. Cílem práce je navrhnout a implementovat program DNMS (Domain Name Management System), který poskytne prostředky pro běžné administrativní úkony spojené se správou DNS domén pro potřeby zaměstnance registrátora, velkoobchodního zákazníka (tj. přeprodejce služeb registrátora, tzv. subregistrátor) a stejně tak i pro vlastníka domény. Důraz je přitom kladen na jednoduchost a přehlednost programu. Program by měl implementovat on-line komunikaci s registrem české domény.cz a evropské.eu, přičemž uživatel by neměl být příliš vystaven odlišnostem obou registrů a administrativní úkony by měly být maximálně zjednodušeny. Stejně tak by program měl být navržen s výhledem na přidání podpory dalších registrů. Vedlejšími požadavky jsou příprava na fakturaci a úhrada administrativního úkonu formou kreditu. 1.2 Představení profilu společnosti ProfiHOSTING s.r.o. Společnost Profihosting s.r.o. je provozovatelem webhostingových služeb ProfiWH.cz a zároveň je akreditovaných registrátorem domén.cz a.eu. V jeho portfóliu se nachází cca aktivních domén, z čehož necelých činí domény registru.cz. Společnost sídlí v Olomouci, ale mezi svými zákazníky má i zahraniční webová studia. Akreditovaným registrátorem.eu domén je již od veřejného spuštění registru (tzv. fáze landrush), takže se podílel na prvních registracích.eu domén vůbec. Realizací daného programu by došlo ke značné úspoře času a práce spojené se správou domén a to zejména domén typu.cz a.eu. Většina pracovních úkonů se zabývá ze 70% registrací, prodloužením či změnami (majitele nebo DNS) u domén. Každá prováděná změna je podmíněna použitím určitého a často i kompliko- 7

8 vaného příkazu ve speciálním programu poskytovaným přímo registrem.cz domén CZ.NIC. Pro.eu domény je nutno se přihlašovat do webového administračního nástroje registru (http://www.registry.eu). Tímto by došlo ke zjednodušení práce s doménami, kdy bychom pouze zadávali požadovanou změnu v rámci jednoho vlastního systému. Doplnění programu o nápovědu by dopomohlo i k širšímu využití ze strany zákazníka, tj. zákazník by byl schopen sám zadávat registrace a změny u domén. Došlo by tak ke zjednodušení celého procesu a urychlení komunikace se zákazníkem. Vysvětlením jednotlivých pojmů by zákazník pochopil, co je po něm požadováno, a do budoucna by již věděl, jak může sám provést základní změny. Iveta Brixová, Doménová specialistka společnosti ProfiHOSTING s.r.o. 8

9 2 Úvod do problematiky domén 2.1 Doména prvního a druhého řádu Doména je stěžejním prvkem symbolické adresace uzlů v internetu. Doménové jméno vyjadřuje příslušnost k nadřazené doméně a plně kvalifikované jméno je vždy unikátní v rámci celého internetu. Adresace serverů v internetu je realizována pomocí unikátních veřejných IP adres. Pomocí IP adresy je možné komunikovat s jakýmkoli serverem a službou na internetu. Tato adresace je nepraktická pro člověka, seznam IP adres se velice špatně pamatuje, proto byl zaveden mechanismus pro překlad symbolických jmen na IP adresy a zpět. Tento mechanismus byl nazván DNS (Domain Name System). DNS umožňuje přiřadit symbolické jméno k jedné nebo více IP adresám, toto symbolické jméno se nazývá doménové jméno. Aby bylo možné zajistit unikátnost doménových jmen v internetu, byla doménová jména rozdělena na domény jednotlivých úrovní, která se oddělují tečkou a jejichž celý zápis za sebou tvoří plně kvalifikované doménové jméno (např. Jednotlivé úrovně jsou číslovány zprava doleva, poslední část je tedy doména 1. úrovně nebo také nejvyšší úrovně (TLD - Top Level Domain), podle příkladu cz. Následuje doména 2. úrovně (SLD Second Level Domain), podle příkladu seznam. Doména www se pak nazývá 3. úrovní atd. Obrázek 1: Hierarchické zobrazení struktury domén jednotlivých úrovní Kořen doménového stromu pak obsahuje veškeré informace o všech TLD. Každé z těchto TLD má pak svůj registr všech svých SLD domén. Každá z těchto domén druhého řádu má svůj seznam domén třetího řádu atd. Na stejném principu roste doménový strom až do libovolného řádu. Informace o každé doméně je fyzicky uložena na DNS serveru, který eviduje jednotlivé záznamy o IP adresách nebo pouze odkazy na další DNS servery, které následují pro danou doménu v 9

10 doménovém stromu, tzv. delegace. [5] Domény nejvyšší úrovně se dále dělí na: generické (gtld) - např. com pro komerční subjekty, org pro nevládní organizace sponzorované (stld) - např. aero, asia, gov, int, jobs národní (označujeme cctld - Country Code Top Level Domain) - např. cz, sk rezervované - např. localhost, example, test TLD domény přiděluje nadnárodní organizace ICANN (Internet Corporation for Assigned Names and Numbers). Tato organizace deleguje správu jednotlivých TLD registrů na regionální a lokální správce, které označuje jako NIC (Network Information Center). Pro registr domény.cz je tímto správcem organizace CZ.NIC a pro registr domény.eu je jím organizace EURid. 2.2 Princip delegace Delegace obecně znamená pověření nějakou rolí nebo funkcí. V případě domén se jedná o pověření přijímat DNS dotazy a posílat DNS odpovědi o IP adresách přiřazených k dané doméně. Proces delegace prochází jednotlivými úrovněmi domén až najde DNS server, který spravuje požadovanou doménu. DNS servery delegujicí zodpovědnost za každou úroveň odpovídají pouze formou NS vět. V některých případech doplněných o věty A (pro IPv4) nebo AAAA (pro IPv6) s IP adresami delegovaných DNS serverů. Zatímco DNS server hledaného doménového jména odpovídá i dalšími typy DNS vět pro danou doménu. Organizace ICANN deleguje správu TLD domén na regionální a lokální správce registrů, ti pak delegují správu domén druhého řádu na smluvní partnery, které označují za registrátory. Registrátoři pak delegují správu domén třetího a nižšího řádu na vlastníky související domény, respektive jejich poskytovatele webhostingu (ISP). Technicky je tento proces realizován prostřednictvím DNS serverů, které jsou určeny pro domény na jednotlivých úrovních. Celý proces začíná u kořenových DNS serverů, které jsou přiřazeny ke kořenové doméně.. Seznam kořenových DNS serverů je veřejně znám a dostupný v podobě seznamu IP adres a mění se pouze výjimečně, protože je na nich závislý celý internet. Kořenová zóna, která je umístěna na těchto serverech, obsahuje seznam všech TLD a k nim přiřazených DNS serverů odpovídajících registrů. ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: 10

11 IN NS m.root-servers.net IN NS k.root-servers.net IN NS h.root-servers.net IN NS e.root-servers.net IN NS l.root-servers.net IN NS a.root-servers.net IN NS j.root-servers.net IN NS g.root-servers.net IN NS c.root-servers.net IN NS b.root-servers.net IN NS f.root-servers.net IN NS d.root-servers.net IN NS i.root-servers.net. Příklad části DNS odpovědi na dotaz na kořenové servery, čili na doménu.. 1 ;; QUESTION SECTION: ;cz. IN NS ;; AUTHORITY SECTION: cz IN NS d.ns.nic.cz. cz IN NS c.ns.nic.cz. cz IN NS b.ns.nic.cz. cz IN NS a.ns.nic.cz. Příklad části odpovědi kořenového DNS serveru na dotaz na doménu cz. Ve stejném duchu odpovídají DNS servery TLD registrů na dotazy na domény druhé úrovně, přičemž v odpovědi vrací seznam DNS serverů ISP, který danou doménu spravuje (dále také technický správce). Tyto DNS servery již nemusí delegovat dále domény nižší úrovně ale mohou přímo odpovídat i na dotazy ostatních typů, které již vracejí tazatelem požadované IP adresy. ;; QUESTION SECTION: ;seznam.cz. IN NS ;; AUTHORITY SECTION: seznam.cz IN NS ans.seznam.cz. seznam.cz IN NS ams.seznam.cz. Příklad části odpovědi DNS serveru registru CZNIC na dotaz na doménu seznam.cz. 1 Jedná se o neautoritativní odpověď z DNS serveru poskytovatele (neautoritativní znamená převzatá). Každý správně nakonfigurovaný DNS server provádějící rekurzivní dotazy má lokálně uloženu zónu. s těmito záznamy, proto je schopen na takovýto dotaz odpovědět obratem bez nutnosti doptávat se dalších DNS serverů. 11

12 ;; QUESTION SECTION: ;seznam.cz. IN A ;; ANSWER SECTION: seznam.cz. 300 IN A Příklad části odpovědi DNS serveru společnosti Seznam a.s. na dotaz na doménu seznam.cz. 2 Registrátoři zodpovídají za správu přiřazených domén druhé úrovně vůči odpovídajícímu registru TLD, řídí se jejich pravidly a provádějí požadavky vlastníků domén, případně dalších zprostředkovatelů (tj. subregistrátor, např. webové studio). 2.3 Životní cyklus domény Životní cyklus domény začíná její registrací a zpravidla končí opětovným uvolněním k registraci pro nové zájemce po vypršení ochranné lhůty. Datem registrace je pak den, kdy byla doména zaregistrována v odpovídajícím registru. Datem expirace se rozumí poslední den lhůty, na kterou byla doména zaregistrována. Dobu registrace pak ovlivňují akce jako samotná registrace domény, prodloužení platnosti nebo v případě registru Eurid změna registrátora. Ochranná lhůta Délka ochranné lhůty a její průběh se u jednotlivých registrů liší, ale v obecné definici se neliší. Ochranná lhůta začíná dnem následujícím po dni expirace domény, po jejímž vypršení je doména uvolněna pro další případnou registraci. Registr CZNIC zavádí ochrannou lhůtu v délce 60 dní, přičemž po uplynutí prvních 30ti dní je zrušena delegace domény (obr. 2). Registr EURid zavádí ochrannou lhůtu v délce 40 dní, přičemž je delegace domény zrušena již na na jejím začátku (obr.3). Registrace domény Registrace probíhá vždy prostřednictvím registrátora na celé násobky roku počínaje datem registrace. Maximální délka registrace je pro oba registry 10 let. Za registraci je účtován registrační poplatek v závislosti na délce registrace. 2 Všimněte si, že odpovídá IP adresou webového serveru, což je odpověď na kterou čeká internetový prohlížeč, aby zobrazil webovou stránku vyhledávače. Tady pomyslný řetěz delegací končí, evidentně nedochází k dalšímu delegování. 12

13 Prodloužení platnosti domény Doba zbývající do expirace domény se nazývá doba registrace, či doba platnosti. Dobu registrace lze kdykoli a opakovaně prodloužit v celých násobcích roku až na 10 let. Tato akce je rovněž zpoplatněna v závislosti na délce prodloužení. Změna registrátora(transfer) V průběhu doby registrace domény může vlastník kdykoli změnit registrátora. Registr CZNIC změnu provede bezplatně a bez jakéhokoli dopadu na délku registrace domény. U registru EURid je změna zpoplatněna a souvisí s ní automatické prodloužení doby registrace o jeden rok. Den expirace zůstává nezměněn, pouze se zvýší o jeden rok nezávisle na tom, kdy došlo ke změně registrátora. Smazání domény Smazáním domény lze doménu uvést předčasně do ochranné lhůty, aniž by došlo ke změně data expirace. Tato funkce se prakticky využívá jen ve výjimečných případech, zpravidla se doména nechá přirozeně přejít do ochranné lhůty a následně je smazána automaticky. Obrázek 2: Registr CZNIC zavádí ochrannou lhůtu v délce 60 dní, přičemž po uplynutí prvních 30 dní je zrušena delegace domény. Změna registrátora nemá vliv na délku registrace domény. 13

14 Obrázek 3: Registr EURid zavádí ochrannou lhůtu v délce 40 dní, přičemž je delegace domény zrušena již na na jejím začátku. Změna registrátora vede k prodloužení doby registrace o 1 rok. 2.4 Podpora IDN Podpora IDN (Internationalized Domain Name - RFC 3490, 3491, 3492 a 3454) znamená podporu znaků národních abeced v názvu domén. V případě české abecedy se jedná o diakritiku, tedy háčky a čárky. Oba registry již technicky tuto podporu mají zavedenu, pouze CZNIC ji dosud neuvedl v platnost. Důvodem je dlouholetý nezájem české internetové komunity. IDN je např. běžným standardem také v Německu u jejich národní domény.de. Překlad IDN domén Překlad internacionalizovaných domén probíhá formou překladu na ASCI reprezentaci již na úrovni internetového prohlížeče, který dále veškeré dotazy na jmenné servery provádí pomocí této formy. Tato forma se nazývá ACE řetězec (ASCII Compatible Encoding) a proces překladu se nazývá "punycode" a je doplněn o funkci "nameprep", která provede převod na kanonický tvar dle národnostních specifik. Některé národní abecedy mohou obsahovat např. vzájemně zaměnitelné znaky. U české abecedy by tato funkce pouze převáděla velká písma na malé. Samotný proces překladu "punycode" probíhá ve třech krocích: 1. Na začátek přeloženého řetězce se vloží předpona "xn ", čímž je signalizováno, že jde o IDN doménu. 2. Všechny čistě ASCII znaky zůstanou beze změny. 3. Zaznamená se pozice ne-asci znaků a jejich ASCI překlad se připojí na konec. Příklad IDN domény: bücher.ch - doména v unicode 14

15 xn bcher-kva.ch - ACE string, který je použit pro dotazy na DNS Registr, který nepodporuje IDN takovýto formát domény zpravidla nepovolí zaregistrovat kvůli dvěma pomlčkám za sebou. Podpora IDN v prohlížečích IDN domény jsou podporovány v prohlížečích ve verzích, které jsou dnes již dávno překonané, proto lze předpokládat, že veškeré moderní prohlížeče budou rovněž podporou disponovat. Microsoft Internet Explorer 7 a vyšší Microsoft Internet Explorer 5 a 6 s inav pluginem od VeriSign Firefox od verze 0.8 Opera od verze 7.11 Safari od verze 1.2 (Mac OS X 10.3) Konqueror (Linux, KDE 3.2 a vyšší, s GNU IDN knihovnou) Seznam minimálních verzí prohlížečů převzat z [3]. Problémy spojené se zavedením IDN Problémy, které přicházejí se zavedením různých národních abeced do domén, souvisejí se zaměnitelností některých stejně nebo podobně vypadajících znaků. Kromě znaků I (velké i) a l (malé L) a 0 (číslice nula) a O (velké o), které jsou v některých fontech opticky zaměnitelné již v základní latince, přibývá celá řada znaků s podobnými vlastnostmi napříč národními abecedami (např. řecké o a o v latince). Těmto neduhům lze částečně čelit omezením na výčet povolených znaků a danou abecedu u národních TLD. Toto omezení by pravděpodobně implementoval i registr CZNIC. Nedává smysl registrovat doménu např. v azbuce na doméně.cz. Registr EURid implementoval výše zmíněné omezení, ale s ohledem na národní abecedy všech členských států v roce 2008 spolu se spuštěním podpory IDN. V roce 2015 registr uveřejnil aktualizaci a implementoval do svého systému mechanismus, který blokuje možnost registrovat doménu, jež může být výše zmíněnou metodou zaměněna za některou z již registrovaných. CZNIC a IDN Registr CZNIC má technicky implementovanou podporu IDN již od počátku vývoje svého registračního systému FRED [4] a od roku 2004 provádí průzkumy trhu vždy v dvouletých intervalech a vždy se stejným výsledkem. Česká uživatelská komunita nemá o zavedení IDN pro českou doménu.cz zájem. V rámci popularizační kampaně spustil CZNIC webovou prezentaci kde vysvětluje potenciál a úskalí IDN. 15

16 3 Popis elektronické komunikace s registry CZ- NIC a EURid Elektronická komunikace mezi registrem a programem registrátora probíhá prostřednictvím protokolu EPP na bázi XML zpráv. Registr CZNIC i EURid využívá pro komunikaci svůj vlastní systém. Elektronická komunikace mezi systémy registru a registrátora probíhá prostřednictvím protokolu EPP (Extensive Provisioning Protokol, dle RFC 3730) na transportní vrstvě TCP/IP (RFC 3734). Veškerá komunikace je šifrována prostřednictvím SSL. Oba registry disponují vlastními implementacemi systému registru. Registr CZNIC navíc svůj systém FRED[4] uvolnil pro veřejnost jako OpenSource a byl dosud nasazen i u několika dalších národních registrů (např. v Estonsku, Makedonii apod.). Veškerá komunikace probíhá ve formě série příkazů a odpovědí. 1 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 2 <command> 3 <check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 4 <domain:check> 5 <domain:name>andalucia.eu</domain:name> 6 </domain:check> 7 </check> 8 </command> 9 </epp> Zdrojový kód 1: Příklad příkazu (check domain - dotaz na dostupnost domény) 16

17 1 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:domain-ext="http ://www.eurid.eu/xml/epp/ 2 domain-ext-1.1" xmlns:idn="http://www.eurid.eu/xml/epp/idn-1.0" 3 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 4 <response><result code="1000"><msg>command completed successfully</ msg></result> 5 <resdata> 6 <domain:chkdata> 7 <domain:cd> 8 <domain:name avail="false">andalucia.eu</domain:name> 9 <domain:reason lang="en">reserved</domain:reason> 10 </domain:cd> 11 </domain:chkdata> 12 </resdata> 13 </response> 14 </epp> Zdrojový kód 2: Příklad odpovědi (doména není volná pro registraci) Kromě EPP serveru zpřístupňují oba registrátoři služby WHOIS a samozřejmě DNS servery pro delegaci domén. Registr EURid navíc zpřístupňuje službu DAS pro přímé dotazovaní výhradně na dostupnost domén pro registraci. Tato služba je vhodná pro masivní dotazování, které může probíhat např. ve chvíli, kdy má být uvolněna atraktivní doména pro novou registraci. V takové chvíli by zainteresovaní registrátoři nadměrně vytěžovali EPP server přílišným množstvím dotazů na dostupnost této domény. Služba DAS je daleko jednodušší a nevyžaduje takové množství systémových prostředků jako EPP server. 3.1 Autentizace a zabezpečení Komunikace s registrem podléhá přihlášení ihned po započetí spojení a přijetí uvítací zprávy (tzv. hello). Přihlášení probíhá prostřednictvím příkazu Login a přiděleného uživatelského jména a hesla. Na konci spojení je vhodné provést rovněž odhlášení příkazem Logout. Oba registry implementují další úroveň zabezpečení. Registr CZNIC vyžaduje započetí spojení s využitím SSL autentizace prostřednictvím certifikátu registrátora, zatímco registr EURid povoluje otevření spojení pouze z předem známých IP adres registrátora. 3.2 Správa kontaktů Kontakt je stěžejním prvkem registru, na který jsou následně navázány domény. Kontakt je reprezentován seznamem informací o fyzické nebo právnické osobě. Kromě základních informací jako je jméno, adresa nebo tel. číslo a , 17

18 může obsahovat další informace jako DIČ, jazyk pro komunikaci apod. Implementace kontaktů a série příkazů pro práci s nimi se u obou registrů zásadně liší. Správu kontaktů prostřednictvím protokolu EPP popisuje RFC Správa kontaktů v registru CZNIC Registr CZNIC zavádí kontakt jako sdílenou entitu napříč celým registrem. Jakýkoli registrátor může tedy tento kontakt přiřadit ke své doméně. Kontakt je možné přiřadit ve všech možných podobách (tj. jako vlastníka domény, či administrativní nebo technický kontakt). Změny kontaktu má oprávnění provádět pouze registrátor-vlastník kontaktu. Změnu takového registrátora lze pak provést příkazem pro transfer kontaktu. Kromě tohoto příkazu registr implementuje standardní sérii příkazů na vytvoření, aktualizaci, ověření existence, zobrazení informaci o kontaktu a smazání. Registr dále přidává nad rámec běžné EPP komunikace příkaz-dotaz na seznam kontaktů ve správě daného registrátora a kromě možnosti uvést DIČ (VAT), přidává jako položku kontaktu také osobní identifikační číslo a jeho typ (č. OP, č. pasu nebo datum narození). Rovněž také nahrazuje dvě poštovní adresy jednou jedinou Správa kontaktů v registru EURid Registr EURid zavádí kontakt jako entitu, která je specifická pro každého registrátora. Jednotlivé kontakty tedy nejsou mezi registrátory sdíleny a tedy v důsledku při změně registrátora domény musejí být odpovídající kontakty znovu vytvořený u nového registrátora. Registr EURid navíc zavádí specifické typy kontaktů. Podle typu kontaktu jsou pak určeny povinné informace při vytváření kontaktu (např. položka číslo faxu u kontaktu technického správce) a jakým způsobem lze kontakt použít (přiřadit). Registr zavádí následující typy kontaktů: Vlastník domény (registrant) - Může být přiřazen k doméně pouze jako její vlastník. Technický správce (tech) - Může být přiřazen k doméně pouze jako tech. správce. Tento kontakt je určen např. pro provozovatele hostingu, kde je doména vedena. Počet kontaktů tohoto typu je v registru omezen na 10. Technický kontakt musí rovněž obsahovat název společnosti a faxové tel. číslo. Na rozdíl od kontaktu vlastníka domény je zde vyžadována právnická osoba. Kontakt typu prodejce (reseller) - Tento kontakt je určen pro přeprodejce služeb registrace domén (tj. subregistrátor nebo např. webové studio). 18

19 Technický kontakt (onsite) - Může být přiřazen k doméně pouze jako onsite kontakt. Tento kontakt je primárně určen pro provozovatele domény jako webmastera či IT oddělení vlastníka domény. Fakturační kontakt registrátora - Jedná se o typ kontaktu, který má každý registrátor vždy právě jeden a je přiřazen ke všem doménám v portfoliu daného registrátora. Vzhledem ke způsobu zpracování kontaktů registrem EURid tento registr implementuje standardní sérii příkazů pro správu kontaktů, přičemž vynechává příkaz pro změnu registrátora. 3.3 Správa domén Registr uchovává o doméně základní informace v podobě údaje o jméně, datu registrace, datu expirace, určeném registrátorovi, odkazu na kontakt vlastníka a seznamu DNS serverů. Podobu entity domény popisuje RFC Rovněž zavádí příkazy pro manipulaci s doménami prostřednictvím protokolu EPP: příkaz pro registraci domény, prodloužení platnosti, změna údajů o doméně, získání informací o doméně, smazání a změna registrátora domény (tzv. transfer) Správa domén v registru CZNIC Registr CZNIC nahrazuje seznam DNS serverů jediným odkazem na entitu skupiny DNS serverů. Dále omezuje způsob změny registrátora, který není možný odložit a provádí se ihned po obdržení příkazu registrem, a zjednodušuje seznam kontaktů na jediný typ admin. Nad rámec standardu také zavádí příkaz pro získání seznamu domén ve správě registrátora Správa domén v registru EURid Registr EURid implementuje správu domén na základě RFC 5731 a z možností vést DNS servery jako samostatné entity nebo naopak jako vlastnosti domén zvolil druhou možnost. Servery DNS lze tedy přidávat a přímo příkazy pro registraci aktualizaci domény. 3.4 Správa skupin DNS serverů Oba registry zavádí podporu seznamů DNS serverů jako samostatných entit, které se následně váží na domény. Nespornou výhodou je snadná aktualizace, která se provádí pouze odebráním nebo přidáním DNS serveru na seznam, změna se projeví v DNS zónách všech navázaných domén aniž by bylo nutné samostatně aktualizovat každou z nich. Skupina DNS serverů může být přiřazena doméně při její registraci nebo při aktualizaci údajů domény odpovídajícím příkazem. 19

20 3.4.1 Správa skupin DNS serverů v registru CZNIC Registr CZNIC rozšiřuje svou definicí RFC 3732 přidáním položky report level a příkazu pro výpis seznamů DNS serverů registrátora. Registr dále vyžaduje, aby měla skupina DNS serverů přiřazen technický kontakt a přidává příkaz pro výpis seznamu skupin DNS serverů dle kontaktu. Skupina DNS serveru musí obsahovat nejméně dva DNS servery, maximálně však deset. Položka report level určuje úroveň technických testů prováděných registrem Správa skupin DNS serverů v registru EURid Registr EURid zavádí vlastní pojetí skupiny DNS serverů prostřednictvím Extension-frameworku EPP protokolu. Jedná se o jednoduchý seznam jmen DNS serverů, ke kterým nelze přiřadit IP adresa na rozdíl od implementace CZNICu. Registr implementuje sérii příkazů pro manipulaci se skupinami DNS serverů v podobě vytvoření, aktualizace, smazání a ověření existence. Skupina DNS serverů smí obsahovat 0-9 DNS serverů. V případě, že má doména nastaveny vlastní DNS servery a je k ní rovněž přiřazena skupina DNS serverů, při generování zónového souboru dojde ke sjednocení obou seznamů. 3.5 Poskytované údaje o účtu registrátora EPP server poskytuje registrátorovi možnost dotázat se na stavové informace ohledně jeho účtu registrátora vedeného v registru jako je zbylý finanční kredit apod. Registr CZNIC rozeznává příkaz CreditInfo a v odpovědi informuje registrátora o stavu kreditu na jeho účtu. Registr EURid zavádí příkaz InfoRegistrar v jehož odpovědi registrátor získá informaci o stavu kreditu, dále pak množství penalizačních bodů (tzv. hitpointů) a počet kreditů nasbíraných za prodloužení domén v rámci marketingové akce EURidu. 3.6 Zprávy zasílané registrem registrátorovi EPP server musí implementovat mechanismus, jak informovat registrátora o změnách v registru, které byly provedeny ze strany registru nebo jiného registrátora. Typickým příkladem je změna registrátora, kdy příkaz na změnu zadává nový registrátor a ten původní musí obdržet informaci, že doména již není nadále v jeho portfoliu (tzv. TRANSFER OUT). EPP protokol zavádí k tomu účelu příkaz POLL. EPP server na tento příkaz reaguje tak, že v odpovědi zašle počet nepřevzatých zpráv a podobu první z nich s jednoznačným identifikátorem. Opětovným zavoláním příkazu s parametrem ack a s použitím tohoto identifikátoru dojde k potvrzení převzetí zprávy a 20

21 jejímu odstranění z fronty registrátora. Následující dotaz pak vrátí další zprávu ve frontě nebo pouze informaci o tom, že je fronta prázdná. Oba registry implementují tento mechanismus podle standardu. HTTPs PUSH Registr EURid navíc zavádí alternativní způsob doručení prostřednictvím HTTPs PUSH. Pokud si registrátor zvolí tuto variantu komunikace na úkor EPP POLL, registr se u každé zprávy pokusí o doručení prostřednictvím metody HTTP 1.1 POST na URL adresu specifikovanou registrátorem. Nevýhodou této metody je omezený počet opakování ze strany registru a tedy i potenciální možnost nedoručení a ztráty informace ze zaslané zprávy. 21

22 4 Implementace Program pro registraci domén 2. úrovně jsem implementoval formou webové aplikace. Původním předpokladem byl program spouštěný na straně klientského počítače, ale o takovéto řešení neměli pracovníci registrátora zájem. Jsou zvyklí obsluhovat webová rozhraní různých registrů a proto preferují stejnou formu i u implementovaného programu. 4.1 Použité technologie a programy Program je naprogramován v programovacím jazyce PHP, uživatelské rozhraní je provedeno prostřednictvím HTML 4.1 a JavaScriptu s pomocí frameworku JQuery. Minimální verze PHP, na které je možné program provozovat je PHP Jako datové úložiště byla použita MySQL relační databáze, především kvůli velmi dobré podpoře v PHP, dosavadním zkušenostem a dostupnému modelovacímu nástroji. MySQL Workbench umožňuje pokročilou správu a modelování dabáze včetně generování inkrementálních změnových souborů např. pro přechod mezi verzemi programu a dále synchronizaci struktury modelu s reálně běžící databází. Jako základní stavební kámen programu byl zvolen webový framework Nette od Davida Grudla ve verzi 2.2. Tento framework poskytuje programu prostředky jako šablonovací systém Latte nebo překladač konfiguračních souborů typu Neon, dále pak zastřešuje základní inicializaci programu a mapování URL adres požadavků na prostředky programu. 4.2 Návrh architektury programu Struktura programu byla navržena tak, aby byly odděleny základní logické celky programu. Kromě dnes již běžně zažitého oddělení databázové vrstvy, aplikační a prezentační logiky byly definovány servisní třídy a tzv. fasády (obr. 4). Nadefinování pojmů z obrázku 4: Servisní třídy (Service) jsou jednoúčelové samostatné třídy, které poskytují aplikaci specifickou službu např. autorizaci a autentizaci uživatele, logování nebo např. obecné zpracování událostí. Fasády (Facade) jsou třídy, které poskytují veřejné rozhraní programu a zapouzdřují vnitřní logiku (podle návrhového vzoru fasáda). Použití fasád je velmi vhodné v případě, že se uvažuje o různých možnostech přístupu k programu - např. webové rozhraní (controller), komunikace se systémy třetích stran (např. pomocí REST API) nebo použití klientské aplikace typu lehký klient, která využívá webových služeb místo implementace kompletní logiky. Entita (Entity) je třída, která představuje reprezentaci objektu systému (např. doménové jméno), její instance pak odpovídá jednomu řádku v tabulce. En- 22

23 tita je pouze nositelem informace, tzv. transportní objekt, neimplementuje vnitřní logiku, pouze validační pravidla. Repozitář (Repository) je třída, která zpřístupňuje metody na dotazování se tabulky a vytváření instancí entit. Entity Manager je prostředek objektově-relačního frameworku, který zajišťuje ukládání entit zpět do databáze (tzv. perzistenci), správu transakcí apod. Obrázek 4: Schéma rozdělení logiky programu (převzato z [7]) Zvolený model architektury programu se podařilo úspěšně implementovat a výsledkem jsou následující fasády, které skrývají vnitřní logiku své části aplikace před ostatními a zpřístupňují pouze své veřejné rozhraní pro interakci. Jednotlivé fasády budou popsány dále v textu. DNMS\Model\DomainContactFacade DNMS\Model\DomainNameFacade DNMS\Model\DomainNSSetFacade DNMS\Model\DomainRegistryFacade DNMS\Model\GroupFacade DNMS\Model\InvoicingOrderFacade DNMS\Model\PricelistFacade DNMS\Model\UserFacade 23

24 Z diagramu na obr. č. 5 je patrné, jak probíhá komunikace mezi jednotlivými úrovněmi architektury. Třídy DomainNamePresenter a DomainContactPresenter implementují webové rozhraní a komunikují výhradně s fasádami (DomainContactFacade a DomainNameFacade), které zpřístupňují data z repozitářů a služby servisních tříd pro komunikaci s registry prostřednictvím vlastního rozhraní. Obrázek 5: Zjednodušený diagram skutečné architektury programu Program je dále rozdělen na tři základní logické moduly: DNMS - základní modul zastřešující vnitřní logiku aplikace, definuje servisní třídy, přistupuje k databázi a řídí chod celého programu Cznic a Eurid - moduly pro komunikaci s jednotlivými registry TLD, implementují zprávy podle specifikace registru a zajišťují komunikaci s nimi 24

25 Adresářová struktura Adresářová struktura programu je rozdělena následovně: /app /app/config /app/cznic /app/data /app/dnms /app/eurid /app/forms /app/model /app/presenters /app/templates /lib /logs /www /tmp Složka app obsahuje vnitřní logiku aplikace, tato složka není přístupná prostřednictvím webového serveru. Složka config obsahuje configurační soubory aplikace Složka Cznic obsahuje soubory modulu pro komunikaci s registrem. Složka obsahuje databázový model pro MySQL Workbench a SQL soubor se strukturou databáze pro instalaci programu. Složka DNMS obsahuje základní modul programu. Složka Eurid obsahuje soubory pro komunikaci s registrem. Složka forms obsahuje třídy zastřešující generování a zpracování webových formulářů. Složka obsahuje třídy definovaných fasád. Složka obsahuje třídy zastřešující zpracování HTTP požadavků. Složka obsahuje šablony webových stránek. Složka obsahuje použité moduly. Složka obsahuje logové soubory programu a modulů registrů. Složka obsahuje soubory pro webové stránky (css styly, javascriptové soubory, obrázky a soubory ke stažení). Pouze tato složka je přístupná přímo prostřednictvím webového prohlížeče. Složka obsahuje dočasné soubory. 4.3 Popis implementace komunikace s registry Komunikace s registrem probíhá formou výměny XML zpráv podle protokolu EPP. EPP server komunikuje s programy registrátorů na portu 700 prostřednictvím transportní vrstvy TCP/IP. Program DNMS odděleně implementuje samotné spojení a generování zpráv, čímž umožňuje lepší testovatelnost závislých tříd použitím pseudoobjektů (tzv. mockování) a zaměnitelnost za jiné typy spojení (např. HTTP). Program zavádí samostatnou třídu DNMS\Connection pro vytvoření spojení s EPP serverem registru a dodává prostředky pro posílání a příjem zpráv, aniž by rozuměla jejich obsahu. Komunikaci s registrem umí zaznamenávat do logu. Třída rovněž implementuje SSL spojení a volitelně provede i přihlášení SSL certifikátem (vyžadováno registrem CZNIC). Třída implementuje rozhraní ConnectionInterface. 25

26 Jednotlivé typy XML zpráv pro registr a jeho odpovědi jsou reprezentovány samostatnými třídami (např. ContactCreateRequest a ContactCreateResponse pro vytvoření kontaktu). Oba registry mají tyto třídy organizovány v samostatných souborech v podadresáři models svého modulu. Třída typu Request představuje šablonu příkazu pro daný registr, zatímco třída typu Response zpracovává data z odpovědi. Oba typy tříd poskytují přístup k položkám zprávy prostřednictvím vlastností objektu (viz ukázka kódu 3). Třídy typu Request rozšiřují abstraktní třídu RequestAbstract, která přidává metody pro automatické generování identifikátoru zprávy (tzv. cltrid) a odeslání zprávy na EPP server. Metoda execute() odešle sestavenou XML zprávu, vrátí objekt typu Response a provede kontrolu identifikátoru zprávy v odpovědi (viz ukázka kódu 3). Pokud se identifikátor liší, vygeneruje výjimku typu RegistryException. 1 ContactCreateRequest $contactcreaterequest */ 2 $contactcreaterequest->name = Jan Baroš ; // nastaví jméno do pož adavku na vytvoření kontaktu 3 ContactCreateResponse $contactcreateresponse */ 4 $contactcreateresponse = $contactcreaterequest->execute(); // odešle příkaz na server 5 print $contactcreateresponse->contact_id; // vytiskne identifikátor právě vytvořeného kontaktu Zdrojový kód 3: Práce s objekty typu RequestAbstract a ResponseAbstract Ve skutečnosti je tento popis funkce metody execute() značně zjednodušený, abychom mohli získat ucelenou představu, musíme nejprve pochopit závislosti této třídy. Třída RequestAbstract rozšiřuje abstraktní třídu XMLMessageAbstract, která zpřístupňuje metody pro zjednodušení práce s XML zprávami obecně, včetně validace. Jak registr CZNIC, tak i EURid zpřístupňují svá.xsd schémata registrátorům. Tyto soubory jsou uloženy v podadresáři schema v obou modulech těchto registrů. Metoda execute() tedy před odesláním XML zprávy do registru volá metodu validateschema() nadřazené třídy XMLMessageAbstract. Pokud zpráva z jakéhokoli důvodu nesplňuje definovaná kritéria, metoda vygeneruje výjimku typu XMLMessageException s popisem nedostatků XML zprávy a k odeslání vůbec nedojde. Vzhledem k tomu, že oba registry implementují penalizační mechanismus 3 za chyby, můžeme tuto bariéru považovat za dobrý krok. Instance všech potomků třídy XMLMessageAbstract, tedy i RequestAbstract, při vytvoření přebírá objekt typu Registry, který třídě zpřístupní seznam jmenných prostorů pro XML zprávy daného registru, metody Login a Logout pro přihlášení 3 Registr CZNIC za každou chybnou zprávu zpomalí reakci na každou další o 1 sekundu. Registr EURid přiděluje za každou chybu tzv. hitpoint a při přesažení stanovené hranice 1000 hitpointů zablokuje registrátorovi přístup na svůj EPP server. Pokud hitpointy nadále nepřibývají po 24ti hodinách nastaví počet hitpointů na 0 a přístup k serveru obnoví. Registrátor může dvakrát za kalendářní měsíc požádat o předčasné odblokování přístupu přes web registru. 26

27 do registru a objekt typu Connection. Nyní, když známe všechny závislosti, můžeme odhalit kompletní implementaci metody execute() třídy RequestAbstract (viz ukázka zdrojového kódu 4). 1 function execute($logout = true) // RequestAbstract::execute 2 { 3 $this->validateschema(); // validuje XML zprávu 4 $response = new $this->_responseclass($this->_reg); // připraví objekt typu ResponseAbstract 5 $conn = $this->_reg->getconnection(); // získá objekt Connection prostřednictvím Registry 6 if ($this->_requiresauthentication &&!$conn->isloggedin()) 7 { 8 $this->_reg->login()->execute(false); // provede přihlášení do registru, pokud již není 9 } 10 $result = $conn->sendandreceive($this->getxml()); // odešle xml zprá vu a příjme odpověd 11 $response->parse($result); // načte XML odpověd do objektu ResponseAbstract 12 $response->validateresponse($this->_cltrid); // provede kontrolu identifikátoru zprávy 13 $this->performlogout($logout); // provede odhlášení a ukončení spojení 14 return $response; // vratí objekt ResponseAbstract 15 } Zdrojový kód 4: Implementace kódu metody RequestAbstract::execute() V ukázce kódu č. 4 si všimněme, že třída typu ResponseAbstract při vytvoření objektu přebírá rovněž objekt typu Registry, je totiž také potomkem třídy XMLMessageAbstract. Dále je patrné, že ve skutečnosti porovnání identifikátoru zprávy v odpovědi provádí třída ResponseAbstract pomocí metody validateresponse(). Kromě této validace metoda validateresponse() kontroluje i návratové kódy v odpovědi a v případě, že identifikuje chybu, vygeneruje výjimku typu ResponseException s popisem chyby. Pro úplnost uvedeme, že třídy Registry podléhají definici rozhraní Registry- Interface, třída RequestAbstract rozhraní RequestInterface a ResponseAbstract rozhraní ResponseInterface. Nyní můžeme konstatovat, že jsme úspěšně implementovali mechanismus pro komunikaci s registrem, který je dostatečně modulární, aby mohl podporovat jakýkoli registr pracující s jakýmkoli protokolem, za předpokladu, že budou implementována definovaná rozhraní. Zároveň jsou jeho součásti samostatně dobře testovatelné. Servisní třídy RegistryService a RegistryServiceFactory V tuto chvíli máme k dispozici způsob, jakým se efektivně můžeme dotazovat jednotlivých registrů. Ale dosud jsme nevyřešili problém možných odlišností ve 27

28 zprávách samotných. Např. použití objektu zprávy Cznic\Model \ContactCreateRequest se liší od stejného typu zprávy Eurid\Model \ContactCreateRequest, byť oba rozšiřují společného předka DNMS\Request\RequestAbstract. V případě této zprávy bude verze Euridu vyžadovat specifikování vlastnosti objektu typ kontaktu, který naopak nebude znát verze CZNICu a bude hlásit chybu, pokud se jej pokusíme ve zprávě nastavit. Pro ostatní části programu to znamená, že musí znát nejen typ příkazu, který chtějí v registru provést, ale také, jaké vlastnosti je možné nastavit, které jsou povinné apod. Vhodným způsobem řešení je odstínit zbylé části aplikace od přímé práce se zprávami pro registr. Zavedením servisní třídy RegistryService pro každý registr a společného rozhraní RegistryServiceInterface definujícího metodu pro každou zprávu typu RequestAbstract docílíme požadovaného efektu (viz ukázka 5.). Všimněme si, že argumentem metody nejsou jednotlivé vlastnosti kontaktu, ale přímo objekt entity. Takto jsme schopni zajistit, že potřebné vlastnosti objektu zprávy nastaví metoda třídy RegistryService. Touto abstrakcí jsme jako vedlejší efekt poskytli řešení pro další odlišnost příkazu ContactCreate a to generování identifikátoru kontaktu v registru. Zatímco Eurid identifikátory přiděluje sám a jsou k dispozici v odpovědi na provedený příkaz, CZNIC vyžaduje specifikování identifikátoru jako součást příkazu. V implementaci metody createcontact třídy RegistryService pro registr CZNIC můžeme zavést funkci generující identifikátor v požadovaném tvaru (např. jméno registrátora + identifikátor entity + jméno a příjmení oddělené pomlčkou a zbavené diakritiky). Vše proběhne transparentně, aniž by se jakkoli změnilo veřejné rozhraní servisní třídy. 1 RegistryService $registryservice */ 2 DomainContact $contact */ 3 $contact_id = $registryservice->createcontact($contact); 4 print $contact_id; Zdrojový kód 5: Volání metody RegistryService::createContact(), která zapouzdřuje kód z ukázky 3 Dále je nutné pamatovat na příkazy, které definuje jen jeden z registrů, pokud metodu implementující tento příkaz zavedeme do společného rozhraní, třídy RegistryService ostatních registrů musí metodu implementovat také. V takovém případě je vhodné generovat výjimku NotImplementedException při zavolání metody. Vhodným přístupem je rovněž poskytnout ostatním částem programu mechanismus pro určení správného registru, se kterým potřebují pracovat. Např. doménu.eu není možné registrovat prostřednictvím servisní třídy Cznic a naopak, rovněž je zbytečné nechat implementaci rozhodovacího mechanismu jiné části programu. 28

29 Poslední abstrakcí, kterou zavedeme je třída RegistryServiceFactory. Tato třída implementuje návrhový vzor Singleton (Jedináček). Dále implementuje metodu getregistrybydomainname(), která vrací servisní třídu registru odpovídajícímu doméně předané v prvním argumentu. Pro ostatní entity v systému je vhodné využít metodu getregistryservices, která vrací pole servisních tříd všech registrů a u každého ověří příslušnost příkazem checktypentity() (např. checkcontact, checknsgroup apod.). Nyní můžeme konstatovat, že jsme úspěšně odstínili komunikaci s registry od ostatních částí programu a vytvořili jsme standardizované rozhraní pro přístup ke službám registru. 4.4 Popis jednotlivých fasád Každá třída implementující návrhový vzor fasáda představuje veřejné rozhraní pro ostatní fasády a webové rozhraní (presentery). Fasáda řídí komunikaci se všemi ostatními vrstvami programu. Dotazuje se na databázovou vrstvu, komunikuje s objekty servisních tříd, přijímá požadavky a odesílá odpovědi zpět prezentační vrstvě. Všechny třídy typu Fasáda implementují rovněž návrhový vzor Jedináček. Zároveň platí společný znak, že každá z nich při vytvoření přebírá aktuálně přihlášeného uživatele (entitu UserAccount) a odkaz na servisní třídu implementující systém oprávnění (třídu DNMS\Security\Permission) ValueObject a CommandObject Než přistoupíme k popisu jednotlivých fasád a jejich specifického účelu, je třeba si představit další prostředek využívaný programem pro zjednodušení práce s hodnotami. Kromě entit využívá program transportní objekty typu ValueObject. ValueObject slouží pro přenos strukturované informace a na rozdíl od entity není svázán strukturou databáze. Specifickou vlastností třídy typu ValueObject je, že všechny povinné informace jsou předávány formou konstruktoru třídy (viz příklad zdroj. kódu 6) a zároveň jsou ve stejnou chvíli validovány. V důsledku tedy není objekt vůbec vytvořen, pokud validace skončila s chybou. Jestliže jakákoli funkce přijímá jako argument ValueObject, může se spolehnout na to, že tento objekt je vždy validní. Jedinou kontrolu, kterou taková funkce musí provést, je ověření, zda jí nebyla předána hodnota null místo požadovaného objektu. Tento přístup je daleko pohodlnější, než mít implementovanou validační funkci, kterou je nutné volat před použitím dané informace. 1 function construct($contact_type, PersonName $person, $company =, $lang, Address $address, Address $ address, PhoneNumber $voice, PhoneNumber $fax = null) Zdrojový kód 6: Ukázka zdrojového kódu třídy Contact 29

30 Jak je patrné z ukázky, třída typu ValueObject se může skládat z dalších tříd typu ValueObject, aby takto přenesl režii na validaci informace, jež může být rovněž použita samostatně v jiném kontextu (např. tel. číslo - ValueObject PhoneNumber). Třída typu ValueObject není určena pro implementaci logiky programu, ale může implementovat např. různé transformace hodnot. ValueObject typu PhoneNumber může tel. číslo rozkládat na mezinárodní volbu, předčíslí a samotné číslo a implementovat metody, které vrátí tel. číslo podle různých zvyklostí (např verzus pro ČR). Program tohoto přístupu vhodně využívá zavedením ValueObjectu typu Price reprezentujícího finanční částku. Třída přebírá pouze číselnou hodnotu a ValueObject typu Currency, reprezentující měnu. Formát, v jakém je částka zobrazena v grafickém rozhraní (GUI) programu je implementován právě ve formě metody tostring() této třídy. Další specifickou vlastností je možnost porovnávat objekty typu ValueObject. Zatímco stejné entity se liší minimálně identifikátorem a je možné na ně pohlížet jen jako různé instance, třídy ValueObject stejného typu jsou vzájemně zaměnitelné v případě, že nesou stejné hodnoty. Všechny třídy typu ValueObject v programu pro tento účel implementují metodu Equals() (viz ukázka kódu č. 7). 1 $phone1 = new PhoneNumber(" "); 2 $phone2 = new PhoneNumber(" "); 3 $phone3 = new PhoneNumber(" "); 4 5 print $phone1->equals($phone2); // vrací True, i když jde o různé instance třídy 6 print $phone1->equals($phone3); // vrací False, jedná se o různá tel. čísla Zdrojový kód 7: Příklad srovnání ValueObjectů stejného typu (PhoneNumber) Specifickým typem třídy typu ValueObject je tzv. CommandObject. Více než specifickou implementací se od běžné třídy ValueObject liší způsobem použití. Třída typu CommandObject nese informaci určenou pro specifický případ použití (vykonání akce). Příkladem akce může být prodloužení doby registrace domény. Požadované informace pak jsou název domény, aktuální datum expirace a počet let k prodloužení. Můžeme tedy zavést třídu typu CommandObject RenewDomain, která bude při vytváření přebírat ValueObject DomainName pro jméno domény, objekt typu DateTime 4 pro datum expirace a číselnou hodnotu pro počet let k prodloužení. Tento CommandObject provede validaci dat, ověří, že není datum expirace v minulosti a po navýšení o daný počet let nedojde k překročení maximální doby registrace. Tato validace by měla proběhnout před vystavením objednávky a znovu při její realizaci, protože mezi vystavením objednávky, přijetím platby a následně její realizací může být časová prodleva, během níž může dojít ke změně 4 DateTime je nativní objekt jazyka PHP. 30

31 vlastností dané domény (např. k prodloužení jiným uživatelem). Program tedy při odeslání sestaví object typu RenewDomain a uloží jej v serializované 5 podobě do položky objednávky. V okamžiku uskutečnění platby, se pokusí znovu sestavit tento objekt z deserializované podoby a přitom se opět provede validace. Třídy typu ValueObject z tohoto důvodu implementují rozhraní Serializable (nativní v PHP), které definuje metody serialize() a unserialize(). Každá z nich při serializaci ukládá číselnou verzi ValueObjectu pro případ, že by došlo ke změnám v objektu, které by mohly ovlivnit zpětný proces deserializace (např. přidaná položka DIČ u ValueObjectu Kontakt). Myšlenka objektů typu ValueObject a CommandObject vychází z přístupu Doménově orientovaného návrhu (Domain Driven Design). V jiných jazycích by se implementovaly formou uživatelsky definovaných datových typů, které bude jazyk PHP podporovat až ve verzi 7 (nyní ve fázi Beta 3, příští verze RC1) Fasáda DomainContactFacade Tato třída typu fasáda zastřešuje veškerou správu kontaktů v programu a v registrech a představuje veřejné metody pro založení nového kontaktu, změnu vlastností, ověření existence nebo smazání. Cílem bylo navrhnout použití kontaktů takovým způsobem, aby uživatel programu nemusel přemýšlet nad tím, pro který registr nebo doménu kontakt zakládá. Vzhledem k tomu, že se jednotlivé položky požadované oběma registry významně neliší, je možné zavést v programu jedinou entitu DomainContact, která ponese informace požadované oběma registry, aniž by to znamenalo komplikaci pro uživatele. Entita DomainContact obsahuje referenci na oba registry, kde si ukládá, pod jakým identifikátorem kontakt vede daný registr a tedy i zda je vůbec registrován. Dále bylo nutné navrhnout způsob práce s kontakty jako takovými. Registr Eurid zavádí typy kontaktů a jejich účel. Ukázalo se, že tento model není ani v rozporu s filozofií registru CZNIC. Diskuse se zástupci registrátora odhalila, že technických kontaktů má registrátor v evidenci jen několik jednotek 6, kromě kontaktů vlastníků domén a vlastního fakturačního kontaktu neeviduje žádné kontakty ostatních podporovaných typů (tj. onsite a reseller). Tento trend si evidentně uvědomil i sám registr Eurid, který počet technických kontaktů omezil na 10 na registrátora. Program tedy implementuje coby typy kontaktů: vlastník domény, technický správce a fakturační kontakt. Fakturační kontakt je v tomto případě interní typ pro potřeby fakturace a objednávek. Úspěšně se tedy podařilo splnit předpoklad a odstínit odlišnosti obou registrů při správě kontaktů. Následuje popis nejdůležitějších metod fasády pro práci s kontakty: Metoda createcontact() vytvoří nový kontakt na základě objektu třídy 5 Serializace převede objekt na textovou reprezentaci, díky níž je schopen opačným procesem, deserializací, získat opět stejný objekt. 6 Registrátor ProfiWH v době dokončování této práce eviduje pouze dva technické kontakty. 31

32 Contact předaném v prvním parametru a uloží jej do databáze. Nově vytvořený kontakt ještě v tuto chvíli není zaregistrován v žádném registru. K jeho registraci dojde až ve chvíli, kdy bude přiřazen k doméně nebo ke skupině DNS serverů. Metoda updatecontact() provádí změny vlastností kontaktů rovněž na základě objektu typu Contact, který nese novou podobu kontaktu. Při ukládání zkontroluje oba registry na existenci daného kontaktu a případně provede i změnu zde. Metoda deletecontact() ověří, zda na tento kontakt nejsou navázány domény nebo skupiny DNS serverů, následně pomocí servisní třídy Registry- ServiceFactory projde všechny registry a smaže kontakt v registru. Pokud vše proběhlo bez problému entitu z programu vymaže. Metoda find() vrací entitu DomainContact odpovídající předanému identifikátoru a případně provede validaci, zda odpovídá požadovanému typu kontaktu předanému v druhém volitelném parametru. Metoda setdisabled() na základě parametru provede zneplatnění nebo opětovnou aktivaci entity. Zneplatněná entita nemůže být dále přiřazována k jiným entitám, toto platí obecně pro všechny entity programu. Metody findalldomaincontact() a listcontactsbytypeautocomplete() poskytují seznam kontaktů pro účely generování přehledů nebo napovídání kontaktů ve formulářích (tzv. funkce autocomplete) Fasáda DomainNSSetFacade Fasáda DomainNSSetFacade zastřešuje veškerou správu skupin DNS serverů a poskytuje své metody ostatním částem programu. Cílem bylo, podobně jako u kontaktů, navrhnout jednotný způsob správy skupin DNS serverů navzdory odlišnostem obou registrů. Přístup obou registrů je v tomto případě velice podobný, proto se i zde podařilo zavést společnou entitu DomainNSSet, která obsahuje společné vlastnosti seznamu DNS serverů a identifikátor pro každý registr. Odlišnost, kterou nepodařilo odstínit byla informace o IP adresách DNS serverů. Zatímco registr CZNIC vede IP adresy výhradně v seznamu DNS serverů, registr EURid povoluje IP adresy pouze v záznamech samotné domény. Je zřejmé, že tato režie musí být přenesena na uživatele programu. Úvodní předpoklad se tedy nepodařilo splnit úplně, ale podařilo se zavést jednotnou entitu pro skupinu DNS serverů. Následuje popis nejdůležitějších metod fasády pro práci se skupinami DNS serverů: Metoda creatensset() vytvoří skupinu DNS serverů na základě objektu třídy NSGroup a uloží jej do databáze. K jeho registraci dojde až ve chvíli, kdy bude přiřazen k doméně. 32

33 Metoda updatensset() provádí změny skupiny na základě objektu typu ServerList, který nese nový seznam DNS serverů. Při ukládání zkontroluje oba registry na existenci dané skupiny a případně provede i změnu zde. Metoda deletensset() ověří, zda na tuto skupinu nejsou navázány domény, následně pomocí servisní třídy RegistryServiceFactory projde všechny registry a smaže skupinu v registru. Pokud vše proběhlo bez problému entitu z programu vymaže. Metoda find() vrací entitu DomainNSSet odpovídající předanému identifikátoru. Metoda setdisabled() na základě parametru provede zneplatnění nebo opětovnou aktivaci entity. Metody findallnssets() a listnssetautocomplete() poskytují seznam skupin DNS serverů pro účely generování přehledů nebo napovídání ve formulářích (tzv. funkce autocomplete) Fasáda DomainNameFacade Fasáda DomainNameFacade zastřešuje veškerou správu domén a poskytuje ostatním částem programu prostředky pro jejich registraci, aktualizaci, prodloužení a převod od jiného registrátora. Všechny tyto funkce provádí prostřednictvím servisních tříd RegistryService a implementuje vnitřní logiku programu pro práci s doménami. Následuje popis nejdůležitějších metod fasády pro práci s doménami: Metoda createdomain() provede registraci domény na základě předaného objektu třídy CreateDomain (CommandObject). Před samotnou registrací ověří dostupnost domény pro registraci, dále zaregistruje kontakt vlastníka domény a technický kontakt, pokud již nebyly zaregistrovány spolu s jinou doménou nebo skupinou serverů. Stejně tak zaregistruje skupinu serverů, pokud je přiřazena a nebyla dosud registrována. Následně uloží entitu DomainName do databáze. Metoda renewdomain() provede prodloužení na základě objektu typu RenewDomain (CommandObject) a nastaví nové datum expirace, které obdrží z odpovědi registru na prodloužení. Metoda deletedomain() provede předčasné smazání domény. Metoda transferdomain() provede převod domény od jiného registrátora na základě jména domény a autorizačního kódu pro převod. Tento kód pro převod obdrží vlastník domény od svého stávajícího registrátora. 33

34 Metoda updatedomain() provede změnu vlastníka domény nebo technického správce, případně přiřazené skupiny DNS nebo přímo nastavení DNS serverů domény (pouze Eurid). Kontakty případně rovněž zaregistruje, pokud dosud nebyly, stejně tak i skupinu DNS serverů. Metoda isavailable() na základě předaného jména ověří dostupnost domény nejprve v systému a následně i v odpovídajícím registru a vrátí pravdivostní hodnotu True, pokud je doména volná pro registraci, jinak vrátí False. Metoda findbydomainname() vrátí DomainName entitu na základně předaného jména domény. Metody listdomainnames() a listdomainnamesforrenewal() poskytují seznam domén pro účely generování přehledů nebo napovídání domén ve formulářích (tzv. funkce autocomplete) Fasáda InvoicingOrderFacade Fasáda InvoicingOrderFacade přidává k fasádě DomainNameFacade prostředky na sestavení objednávky na jednotlivé akce, které jsou podmíněny platbou. Metody třídy DomainNameFacade obaluje svou interní logikou a přímo je volá až ve chvíli uhrazené objednávky, přičemž využívá mechanismus serializace tříd typu CommandObject popsaný v první části kapitoly. Objednávka může nabývat následujících stavů: Čeká na platbu - Výchozí stav při vytvoření nové objednávky, všechny položky objednávky kopírují tento stav. Zaplacená - Ve chvíli, kdy je objednávka označena jako zaplacená jsou všechny její položky převedeny do stavu čeká na zpracování a pokusí se je zpracovat vyvoláním přiřazeného objektu typu CommandObject a zavoláním odpovídající metody fasády DomainNameFacade. Pokud vše proběhne v pořádku, označí se jako dokončeno, v opačném případě jako chyba s popisem chyby. Zrušená - Objednávka může být manuálně zrušena a to pouze pokud dosud nebyla zaplacena. Dokončená - Objednávka se automaticky označí jako zaplacená ve chvíli, kdy všechny její položky budou ve stavu dokončeno. Následuje popis nejdůležitějších metod fasády: Metoda createdomain() na základě předaného objektu typu CreateDomain dohledá cenu v ceníku přiřazeného skupině uživatele, sestaví objednávku a uloží ji do databáze jako entitu InvoicingOrder, jednotlivé položky objednávky pak jako entity typu InvoicingOrderItem. 34

35 Metoda domainrenew() pracuje analogicky k metodě createdomain() pouze pracuje na základě předaného objektu typu RenewDomain. Metoda findbyorderno() vrátí entitu InvoicingOrder na základě předaného čísla objednávky. Metody listactiveorders(), listordersindue() a listcompletedorders() poskytují seznam objednávek pro účely generování přehledů objednávek, v následujícím pořadí: nedokončené objednávky, objednávky po splatnosti a dokončené objednávky (tj. včetně zrušených) Fasáda InvoicingPricelistFacade Fasáda InvoicingPricelistFacade poskytuje zbylým částem programu prostředky pro vytvoření nového ceníku, aktualizaci, smazání nebo blokování a dotazování se na ceny jednotlivých položek ceníku. Tyto funkcionality poskytuje prostřednictvím následujících metod: Metoda CreatePricelist() na základě předaného jména ceníku, měny a seznamu cen položek uloží do databáze entitu InvoicingPricelist a pro jednotlivé položky entity InvoicingPricelistItem. Metoda UpdatePricelist() provede aktualizaci ceníku a jeho položek na základě předaného seznamu cen. Metoda DeletePricelist() ověří, zda na ceník nejsou navázány nějaké uživatelské skupiny a následně ceník z programu vymaže. Metoda findpricelistbycode() vrátí entitu InvoicingPricelist na základě předaného identifikátoru ceníku. Metoda getpricelistitemsbyaction() na základě předaného jména domény a typu ceníkové položky vrátí indexované pole cen pro danou akci při objednání s periodou 1-10 let. Metody listactivepricelists() a findallpricelists() poskytují seznam ceníků pro účely generování přehledů objednávek, v následujícím pořadí: neblokované ceníky a všechny ceníky. 4.5 Schéma databáze a komunikace s databází Jako abstrakční vrstva zapouzdřující komunikaci s databází byl použit ORM framework Doctrine2 [8] ve verzi 2.3. ORM (Object Relation Mapping) slouží pro automatické generování objektů reprezentující záznamy v tabulkách a relační vazby mezi nimi, tyto objekty nazýváme entity. Různé ORM frameworky umožňují různý přístup k vlastnostem jednotlivých entit. Velmi často používají magické funkce (tj. prostředky pro přetěžování neexistujících vlastností nebo metod) a vlastnosti pro přístup k informacím uloženým v entitě. S tímto si bohužel 35

36 neporadí většina programátorských editorů (IDE), není schopna tyto vlastnosti napovídat při psaní názvů (funkce IDE označovaná jako autocomple, intelisense apod.) nebo validovat a upozornit na případné překlepy. Doctrine2 má opačný přístup, třídy entit fyzicky generuje do souborového systému, vlastnosti objektu zapouzdřuje (jsou označeny jako privátní) a zpřístupňuje je pomocí tzv. getterů a setterů. Jedná se o metody objektu, které umožňují získání a změnu vlastnosti objektu. Jmenná konvence určuje, že getter je pojmenován getnazevvlastnosti() a setter je pojmenován setnazevvlastnosti ($hodnota). Výhodou tohoto přístupu mimo odstranění výše popsaných neduhů je také možnost definovat rozhraní pro danou entitu, což není při dynamickém přístupu možné. Jednotlivé třídy entit generované Doctrine jsou umístěny ve složce projektu v podsložce app/ DNMS/Entity/Om, o úroveň výše jsou uloženy stejně pojmenované třídy, které generované třídy rozšiřují. Tímto je zajištěno, že veškeré ruční úpravy entit zůstanou nedotčeny při přegenerování tříd pomocí Doctrine. Pro každou tabulku databáze je vždy generována právě jedna třída entity. Ve stejné složce je umístěna podsložka Repository ve které se nachází třídy zajišťující uložení dat z entit zpět do databáze (tzv. perzistenci) a dotazování na jednotlivé entity. Pro každou entitu je zde jedna třída typu Repository. Třída Repository implementuje návrhový vzor Singleton. Nejdůležitější částí frameworku Doctrine je tzv. EntityManager, který se stará o přímý přístup k databázi a umožňuje provádění transakcí apod. Schéma databáze části aplikace, která se stará o správu domén, je zobrazeno na obr. č. 6. Z obrázku jsou patrné jednotlivé vazby mezi tabulkami. Přehlednost schématu komplikuje více vazeb mezi tabulkou domain_contact a domain_name, protože je s každou doménou svázáno několik kontaktů v různých rolí (pro připomenutí je to vlastník, technický správce a fakturační kontakt). Tabulka domain_contact je reprezentována v programu entitou DomainContact a uchovává informace o vlastnostech každého kontaktu jako je jméno, adresa a kontaktní informace. Kromě toho definuje vazby na vlastníka kontaktu (user_account a user_group), specifikuje typ kontaktu a eviduje identifikátory pro referenci na objekt v registru (registry_id pro EURid a cznic_id pro CZNIC). Každá tabulka obsahuje sloupce created a updated, které Doctrine automaticky nastaví na datum a čas vytvoření entity, respektive poslední aktualizace. Tabulka domain_nsset je reprezentována entitou DomainNsset a uchovává informace o skupinách DNS serverů. Kromě jména, reference na domain_contact v podobě technického kontaktu a položek pro celkem 9 DNS serverů jsou zde opět identifikátory pro referenci na objekt v registru. Tabulka domain_name je reprezentována entitou DomainName a uchovává informace o vlastnostech domén jako jméno, datum expirace a reference na navázané kontakty, skupinu DNS serverů a tabulky domain_registry a domain_tld. Což jsou pomocné tabulky pro sestavování přehledů podle TLD a registru. Tabulka domain_registry uchovává stavové informace o registru jako dostupný kredit na účtu registrátora nebo počet penalizačních bodů v pří- 36

37 padě EURidu. Obrázek 6: Schéma databáze z pohledu správy domén Schéma databáze části aplikace, která se stará o správu objednávek a ceníků, je zobrazeno na obr. č. 7. Je zde patrná vazba mezi ceníkem (invoicing_pricelist), ceníkovými položkami (invoicing_pricelist_item) a TLD (domain_tld). Ceník je sestaven z cen, které se pro jednotlivé TLD liší. Dále je patrná vazba mezi fakturačním kontaktem reprezentovaným tabulkou domain_contact a objednávkou (invoicing_order), stejně jako mezi položkami objednávky (invoicing_order_item) a objednávkou. U položky objednávky si všiměme sloupce command, do kterého se při vytvoření položky objednávky uloží serializovaný objekt typu CommandObject. Z nákresu dále není patrná vazba mezi položkou objednávky a tabulkou domain_name, ta je důležitá pro výpis objednávek vztažených k jednotlivé doméně. 37

38 Obrázek 7: Schéma databáze z pohledu správy objednávek 4.6 Zabezpečení programu Webová aplikace, která je permanentně dostupná na serveru prostřednictvím internetu, musí nutně řešit zabezpečení proti nepovolenému přístupu. Program DNMS vyžaduje přihlášení uživatelským účtem a rozděluje role oprávnění, které jsou pak účtům přiřazeny účtům. Hesla k uživatelským účtu jsou uložena v databázi v zašifrované podobě tak, aby nebyla zneužitelná v případě, že by se útočníkovi podařilo data z databáze přečíst. Heslo je zašifrováno pomocí primitivní funkce jazyka crypt() (tj. vestavěná funkce) s přidáním druhého řetězce (tzv. salt) pro zkomplikování reverzního způsobu zjištění hesla. Dále program zajišťuje automatické odhlášení uživatele při neaktivitě po zvolený časový úsek. Ve výchozím nastavení program provede automatické odhlášení po 15 minutách neaktivity uživatele. Vzhledem k tomu, že je heslo při přihlášení přenášeno mezi prohlížečem klienta a programem v čitelné textové podobě, je nutné program zpřístupnit na webovém serveru výhradně prostřednictvím zašifrovaného spojení (HTTPs). Registrátor by si pro tento účel měl zajistit důvěryhodný certifikát od některé z certifikačních autorit s širokou podporou v prohlížečích (např. Thawte, Verisign či RapidSSL). České certifikační autority nejsou pro tento účel příliš vhodné díky jejich chabé podpoře v prohlížečích. Nelze se rovněž spoléhat ani na certifikační autority distribuované s operačním systémem. Prohlížeč Firefox systémové 38

POKYNY K REGISTRACI PROFILU ZADAVATELE

POKYNY K REGISTRACI PROFILU ZADAVATELE POKYNY K REGISTRACI PROFILU ZADAVATELE Stav ke dni 4. 12. 2012 Obsah: 1 Úvod... 3 1.1 Podmínky provozu... 3 1.2 Pokyny k užívání dokumentu... 3 2 Registrace profilu zadavatele... 4 2.1 Přihlášení uživatele...

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

Pravidla komunikace LRR

Pravidla komunikace LRR Pravidla komunikace LRR Verze 20040801 V platnosti od 1.8.2004 0. OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů subjektů

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] implementace přenosu informace o doručení SMS verze 166 / 1.3.2012 1 Obsah 1 Implementace platebního systému 3 1.1 Nároky platebního systému na klienta 3 1.2 Komunikace

Více

Domain Name System (DNS)

Domain Name System (DNS) Domain Name System (DNS) Co je DNS RFC 1034, 1035 řeší vzájemné převody mezi jmény a IP adresami rozšířeno na distribuovanou databází informací jména nemají žádnou vazbu s topologií sítě hierarchická struktura

Více

Zabezpečení proti SQL injection

Zabezpečení proti SQL injection Zabezpečení proti SQL injection ESO9 intranet a.s. Zpracoval: Tomáš Urych U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 19.9.2012 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Urych Tomáš www.eso9.cz

Více

Pravidla komunikace registrátora ZONER software, a.s. V platnosti od 1.8.2004 OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů

Více

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény DNSSEC Validátor - doplněk prohlížečů proti podvržení domény CZ.NIC z.s.p.o. Martin Straka / martin.straka@nic.cz Konference Internet a Technologie 12 24.11.2012 1 Obsah prezentace Stručný úvod do DNS

Více

Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace )

Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace ) Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace ) 1. ÚVODNÍ USTANOVENÍ 1.1. Tato Pravidla registrace stanoví pravidla pro registraci

Více

Pravidla komunikace registrátora Web4u s.r.o.

Pravidla komunikace registrátora Web4u s.r.o. Pravidla komunikace registrátora Web4u s.r.o. V platnosti od 24.10.2003 OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů subjektů

Více

Nová áplikáce etesty Př í přává PC ž ádátele

Nová áplikáce etesty Př í přává PC ž ádátele Nová áplikáce etesty Př í přává PC ž ádátele Verze 0.6 Datum aktualizace 20. 12. 2014 Obsah 1 Příprava PC žadatele... 2 1.1 Splnění technických požadavků... 2 1.2 Prostředí PC pro žadatele... 2 1.3 Příprava

Více

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen.

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen. 9. Systém DNS Studijní cíl Představíme si problematiku struktury a tvorby doménových jmen. Doba nutná k nastudování 1,5 hodiny Uvedená kapitola vychází ze zdroje [1]. Celý Internet je z hlediska pojmenovávání

Více

Smluvní podmínky pro užívání a správu domén ".sk" u spol. General Registry. Provozovatel. 1. Základní ujednání

Smluvní podmínky pro užívání a správu domén .sk u spol. General Registry. Provozovatel. 1. Základní ujednání u spol. General Registry Provozovatel Provozovatelem jsou v následujícím dokumentu myšleny společnosti: 1. General Registry, s.r.o. Žižkova 1 370 01 České Budějovice Česká republika IČ: 26027267 DIČ:CZ26027267

Více

Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS

Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS Aplikační vrstva Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace RIP DNS TELNET HTTP SNMP RTP SMTP FTP port UDP TCP IP 1 Aplikační

Více

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Český metrologický institut sídlem Okružní 31, 638 00 Brno IČ: 00177016 Verze dokumentu: 1.1 Jazyk dokumentu: český Status: testovací

Více

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Český metrologický institut sídlem Okružní 31, 638 00 Brno IČ: 00177016 Verze dokumentu: 1.0 Jazyk dokumentu: český Status: testovací

Více

Artlingua Translation API

Artlingua Translation API Artlingua Translation API Dokumentace Jan Šváb, Artlingua, a.s. 2015 Revize: 2015-09-22 - verze API : v1 Obsah Obsah... 2 Předávání dokumentů k překladu... 3 Implementace klientské aplikace pro Translation

Více

Informační systém pro vedení živnostenského rejstříku IS RŽP

Informační systém pro vedení živnostenského rejstříku IS RŽP Informační systém pro vedení živnostenského rejstříku IS RŽP Ing. Miloslav Marčan odbor informatiky MPO Praha říjen 2007 Ministerstvo průmyslu a obchodu Agenda Historie projektu Cíle projektu IS RŽP Legislativní

Více

Úvod do informatiky 5)

Úvod do informatiky 5) PŘEHLED PŘEDNÁŠKY Internet Protokol a služba Jmenná služba (DNS) URL adresa Elektronická pošta Přenos souborů (FTP) World Wide Web (WWW) Téměř zapomenuté služby 1 INTERNET 2 PROTOKOL A SLUŽBA Protokol

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

Pravidla registrace doménových jmen v cctld.cz

Pravidla registrace doménových jmen v cctld.cz Pravidla registrace doménových jmen v cctld.cz V platnosti od 1.10.2007 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 29. Otázka : Zpracování událostí: mechanismus událostí a jejich zpracování (Event/Listener), nepřímá invokace (Observer/Observable). Obsah : 1. Mechanisums

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží Číslo projektu CZ.1.07/1.5.00/34.0394 Škola SOŠ a SOU Hustopeče, Masarykovo nám. 1 Autor Ing. Miriam Sedláčková Číslo VY_32_INOVACE_ICT.3.01 Název Teorie internetu- úvod Téma hodiny Teorie internetu Předmět

Více

Počítačové sítě Aplikační vrstva Domain Name System (DNS)

Počítačové sítě Aplikační vrstva Domain Name System (DNS) Aplikační vrstva Domain Name System (DNS) DNS je distribuovaná databáze, kterou používají TCP/IP aplikace k mapování doménových jmen do IP adres (a naopak) DNS informace jsou rozprostřeny po množině DNS

Více

3. PRODLOUŢENÍ REGISTRACE DOMÉNOVÉHO JMÉNA 4. DELEGACE DOMÉNOVÉHO JMÉNA

3. PRODLOUŢENÍ REGISTRACE DOMÉNOVÉHO JMÉNA 4. DELEGACE DOMÉNOVÉHO JMÉNA Pravidla registrace doménových jmen v cctld.cz V platnosti od 1.11.2011 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Internetový obchod ES Pohoda Web Revolution

Internetový obchod ES Pohoda Web Revolution Internetový obchod ES Pohoda Web Revolution Uživatelský manuál propojení na ES Pohoda Verze 1.0 Web Revolution s.r.o. 2010 Internetový obchod ES Pohoda Uživatelský manuál na propojení na ES Pohoda Přehled

Více

Katalog egon služeb verze: 0.01

Katalog egon služeb verze: 0.01 Katalog egon služeb verze: 0.01 Historie verzí Verze Datum Popis 0.01 20.7.2011 egon služby prototypu OBSAH 1 Úvod... 5 1.1 Členění dokumentu... 5 1.2 Třídy služeb... 5 1.3 SLA služeb... 6 1.3.1 SLA-01...

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] popis platební metody MTSMS a průběhu platby verze / 9..0 Obsah Přehled platebních metod. MTSMS. MTSMS [erotický obsah] Průběh platby. Platba s přesměrování na platební

Více

Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period

Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period OBSAH 1. VYMEZENÍ POJMŮ...2 2. PŘEDMĚT A ROZSAH PRAVIDEL...2 3. OMEZENÍ ŽÁDOSTÍ NA DOMÉNOVÁ

Více

Web. Získání informace z internetu Grafické zobrazení dat a jejich struktura Rozšíření funkcí pomocí serveru Rozšíření funkcí pomocí prohlížeče

Web. Získání informace z internetu Grafické zobrazení dat a jejich struktura Rozšíření funkcí pomocí serveru Rozšíření funkcí pomocí prohlížeče Web Získání informace z internetu Grafické zobrazení dat a jejich struktura Rozšíření funkcí pomocí serveru Rozšíření funkcí pomocí prohlížeče Technologické trendy v AV tvorbě, Web 2 DNS Domain Name Systém

Více

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele Provozní dokumentace Seznam orgánů veřejné moci Příručka pro běžného uživatele Vytvořeno dne: 7. 7. 2011 Aktualizováno: 11. 2. 2015 Verze: 2.2 2015 MVČR Obsah Příručka pro běžného uživatele 1 Úvod...3

Více

plussystem Příručka k instalaci systému

plussystem Příručka k instalaci systému plussystem Příručka k instalaci systému Tato příručka je určena zejména prodejcům systému a případně koncovým uživatelům. Poskytuje návod, jak provést potřebná nastavení komponent. ITFutuRe s.r.o. 26.2.2015

Více

Příručka nastavení funkcí snímání

Příručka nastavení funkcí snímání Příručka nastavení funkcí snímání WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_CS 2004. Všechna práva vyhrazena. Uplatňovaná ochrana autorských práv se vztahuje na všechny formy a záležitosti

Více

27 Evidence kasiček. Popis modulu. Záložka Organizované sbírky

27 Evidence kasiček. Popis modulu. Záložka Organizované sbírky 27 Evidence kasiček Uživatelský modul Evidence kasiček realizuje evidenci všech pořádaných sbírek, jednotlivých kasiček sbírky, dále pak evidenci výběrů kasiček s návazností na pokladnu (příjem výběru

Více

MojeID: Pravidla motivačního programu pro poskytovatele služeb

MojeID: Pravidla motivačního programu pro poskytovatele služeb MojeID: Pravidla motivačního programu pro poskytovatele služeb V platnosti od 1. 3. 2015 1 Vyhlašovatel CZ.NIC, z. s. p. o. Milešovská 5, 130 00 Praha 3 IČ: 67985726 DIČ: CZ67985726 Zapsáno ve spolkovém

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5 Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky

Více

Dokumentace k API SSLmarketu. verze 1.3

Dokumentace k API SSLmarketu. verze 1.3 Dokumentace k API SSLmarketu verze 1.3 ZONER Software a.s. 2015 Obsah Úvod... 3 Legenda... 3 Funkce API... 4 Návratové hodnoty... 8 SWAPI - přihlašovací údaje... 8 SWAPI - nastavení výchozích údajů...

Více

Pravidla registrace doménových jmen v cctld.cz

Pravidla registrace doménových jmen v cctld.cz Pravidla registrace doménových jmen v cctld.cz V platnosti od 30.9.2008 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Webové rozhraní pro datové úložiště. Obhajoba bakalářské práce Radek Šipka, jaro 2009

Webové rozhraní pro datové úložiště. Obhajoba bakalářské práce Radek Šipka, jaro 2009 Webové rozhraní pro datové úložiště Obhajoba bakalářské práce Radek Šipka, jaro 2009 Úvod Cílem práce bylo reimplementovat stávající webové rozhraní datového úložiště MU. Obsah prezentace Úložiště nasazené

Více

Už ivatelska dokumentace

Už ivatelska dokumentace Už ivatelska dokumentace Aplikace Portál úspěšných projektů je určena k publikování informací o projektech realizovaných za přispění některého z Operačních programů v gesci Ministerstva vnitra České republiky.

Více

Seznámení s ISPOP 2012. Oddělení ISPOP a IRZ CENIA, česká informační agentura životního prostředí

Seznámení s ISPOP 2012. Oddělení ISPOP a IRZ CENIA, česká informační agentura životního prostředí Seznámení s ISPOP 2012 Oddělení ISPOP a IRZ CENIA, česká informační agentura životního prostředí ISPOP Integrovaný systém plnění ohlašovacích povinností zákon č. 25/2008 Sb., o integrovaném registru znečišťování

Více

Obchodní podmínky pro webhosting a domény. Definice a rozsah poskytovaných služeb

Obchodní podmínky pro webhosting a domény. Definice a rozsah poskytovaných služeb Obchodní podmínky pro webhosting a domény Definice a rozsah poskytovaných služeb Předmětem služby poskytované zákazníkovi je provoz virtuálního serveru (tzv. webhostingu) na počítačové síti Internet. Pod

Více

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Webové aplikace Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Harmonogram Dopolední blok 9:00 12:30 Ing. Dostal Úvod, XHTML + CSS Ing. Brada,

Více

Dokumentace ke službě SMS Connect. www.smsbrana.cz

Dokumentace ke službě SMS Connect. www.smsbrana.cz Dokumentace ke službě SMS Connect www.smsbrana.cz Obsah 1 ZÁKLADNÍ INFORMACE... 3 1.1 Aktivace služby SMS Connect... 3 1.2 Přístupové údaje... 3 1.3 Přístupový bod služby URL adresa pro SMS Connect...

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

Audit bezpečnosti počítačové sítě. Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz

Audit bezpečnosti počítačové sítě. Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz Audit bezpečnosti počítačové sítě Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz Zadání Prověřit bezpečnost v dané počítačové síti (cca 180 klientských stanic) Nejsou povoleny destruktivní

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

SRSW4IT Inventarizační SW. Prezentace aplikace. Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek

SRSW4IT Inventarizační SW. Prezentace aplikace. Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek Prezentace aplikace Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek Osnova Úvod Programovací jazyk - PHP Etapy vývoje Funkce aplikace Co SW umí Na čem se pracuje Vize do budoucna Úvod Úvod Inspirováno

Více

Technologické postupy práce s aktovkou IS MPP

Technologické postupy práce s aktovkou IS MPP Technologické postupy práce s aktovkou IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Technologické postupy práce

Více

Internet Information Services (IIS) 6.0

Internet Information Services (IIS) 6.0 Internet Information Services (IIS) 6.0 V operačním systému Windows Server 2003 je obsažena i služba IIS v 6.0. Služba IIS poskytuje jak www server tak i některé další služby (FTP, NNTP,...). Jedná se

Více

Certifikační protokol

Certifikační protokol Certifikační protokol Registrátor Webové stránky ACTIVE 24, s.r.o. www.active24.cz Certifikace platná k datu : 1.9.2013 Získaný počet hvězdiček ***** Výsledky certifikace Kategorie Max. možný počet Získaný

Více

Informační systém webhostingu

Informační systém webhostingu VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA INFORMAČNÍ SYSTÉMY A DATOVÉ SKLADY Informační systém webhostingu semestrální projekt Analýza Číslo skupiny: 4 Členové: Filip Bartman Jakub Vaněk Jan Šrámek

Více

Po ukončení tohoto kurzu budete schopni:

Po ukončení tohoto kurzu budete schopni: PRÁCE S INTERNETEM A KOMUNIKACE Hana Rohrová, Roman Rohr Cíle kurzu Po ukončení tohoto kurzu budete schopni: porozumět základním pojmům spojeným s používáním Internetu, dodržovat bezpečnostní opatření

Více

Stručný průvodce aplikací Sběr dat pro CEP a CEZ

Stručný průvodce aplikací Sběr dat pro CEP a CEZ Stručný průvodce aplikací Sběr dat pro CEP a CEZ (verze 1.0) Rada pro výzkum a vývoj Úřad vlády ČR Určeno necertifikovanému dodavateli dat RVV 2003 1. Vstup do aplikace Informace pro uživatele, uživatelské

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

Analýza Systém Správce

Analýza Systém Správce Analýza Systém Správce Toto je analýza aplikace Systém Správce, která slouží k alokaci zaměstnanců vedených v databázi do týmů. Jedná se o pomůcku projektových manažerů. Rozbor požadavků Funkční požadavky

Více

Maturitní projekt do IVT Pavel Doleček

Maturitní projekt do IVT Pavel Doleček Maturitní projekt do IVT Pavel Doleček CO FILMBOOK JE Filmbook je uzavřená webová aplikace pro celkovou správu informací a dat souvisejících se sledováním filmů. Primárně je zaměřen na uchovávání a spravování

Více

1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele.

1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele. 1. Vstup do aplikace Na adrese: http://i.statnisprava.cz 2. První stránka aplikace 1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele. 2. Poté budete přesměrováni na stránku

Více

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Nástroje pro poskytování součinnosti 1.1 Help desk Poskytovatel vytvoří a zajistí službu pro hlášení vad/požadavků/připomínek (dále

Více

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro administrátora zřizované organizace

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro administrátora zřizované organizace Provozní dokumentace Seznam orgánů veřejné moci Příručka pro administrátora zřizované organizace Vytvořeno dne: 30. 6. 2011 Aktualizováno: 17. 10. 2014 Verze: 2.1 2014 MVČR Obsah Příručka pro administrátora

Více

Modul Kontakt s klientem SSP. OKcentrum. Uživatelská příručka. Poskytování součinnosti ÚP ČR

Modul Kontakt s klientem SSP. OKcentrum. Uživatelská příručka. Poskytování součinnosti ÚP ČR Modul Kontakt s klientem SSP OKcentrum Uživatelská příručka Poskytování součinnosti ÚP ČR OKsystem a.s. 2015 1. Obsah 1. OBSAH... 2 2. ZÁKLADNÍ INFORMACE... 2 2.1 Základní pojmy... 2 2.2 Přihlášení uživatele...

Více

Internetové služby isenzor

Internetové služby isenzor Internetové služby isenzor Aktuální snímek z webové kamery nebo aktuální teplota umístěná na vašich stránkách představují překvapivě účinný a neotřelý způsob, jak na vaše stránky přilákat nové a zejména

Více

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka Deutsche Bank, pobočka Praha Verze 8.2 červenec 2009 Obsah Obsah... 1 Úvod... 2 Detailní popis... 3 Zavedení

Více

Pravidla registrace doménových jmen v ENUM

Pravidla registrace doménových jmen v ENUM Pravidla registrace doménových jmen v ENUM V platnosti od 1.10.2007 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé a dalších úrovní pod doménou.0.2.4.e164.arpa

Více

ISPOP v roce 2015. Obsah prezentace ISPOP. CENIA, Praha 5.1.2015 1. Úvod, registrace, uživatelský účet

ISPOP v roce 2015. Obsah prezentace ISPOP. CENIA, Praha 5.1.2015 1. Úvod, registrace, uživatelský účet ISPOP v roce 2015 Ing. Pavla Jirůtková - oddělení ISPOP a IRZ CENIA, česká informační agentura životního prostředí Seminář pro ohlašovatele, Ekomonitor, 13.,14.,15.1.2015 Obsah prezentace Úvod, registrace,

Více

Obchodní podmínky registračního systému Právnické fakulty Masarykovy univerzity

Obchodní podmínky registračního systému Právnické fakulty Masarykovy univerzity Obchodní podmínky registračního systému Právnické fakulty Masarykovy univerzity Tyto obchodní podmínky upravují registraci a úhradu účastnických poplatků prostřednictvím registračního systému Právnické

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Centrální autentizační webový informační systém

Centrální autentizační webový informační systém Centrální autentizační webový informační systém Vypracoval : Jaromír Koníček Datum vypracování: 24..2006 Case nástroj: Enterprise Architekt v. 4.50 Obsah. Úvod... 3.. Použité terminologie... 3 2. Popis

Více

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv [ 1 ] [ 2 ] Přístup pro účastníky správních řízení Přístup pro farmaceutické firmy [ 3 ] Program prezentace Cíle prezentovaného řešení Představení prezentovaného řešení Diskuse a dotazy [ 4 ] Cíle prezentovaného

Více

Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat

Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat Obsah 1 Úvod... 2 2 Nastavení přístupů k rozhraní... 2 2.1 Popis obrazovky... 2 2.1.1 Nastavení datových extraktů z banky...

Více

P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing.

P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing. P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing. Tomáš Petránek tomas@petranek.eu Karviná, 21. 10. 2011 Obsah prezentace 1. Okolnosti

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Knot DNS Resolver. Modulární rekurzivní resolver. Karel Slaný karel.slany@nic.cz 13. 11. 2015

Knot DNS Resolver. Modulární rekurzivní resolver. Karel Slaný karel.slany@nic.cz 13. 11. 2015 Knot DNS Resolver Modulární rekurzivní resolver Karel Slaný karel.slany@nic.cz 13. 11. 2015 Obsah Co je KNOT Resolver Části resolveru Funkce a konfigurace Integrační testování Co je Knot DNS Resolver Minimalistický

Více

Kerio IMAP Migration Tool

Kerio IMAP Migration Tool Kerio IMAP Migration Tool 2011 Kerio Technologies s.r.o. Všechna práva vyhrazena. Verze: 7.2 1 Úvod Tato příručka slouží jako průvodce migrací uživatelských účtů a dat z libovolného IMAP serveru do úložiště

Více

mysh.cz Smluvní ujednání Platné od 1. února 2007 UAM Czech Republic s.r.o. Limuzská 2110/8 100 00 Praha 10 Strašnice

mysh.cz Smluvní ujednání Platné od 1. února 2007 UAM Czech Republic s.r.o. Limuzská 2110/8 100 00 Praha 10 Strašnice Smluvní ujednání Platné od 1. února 2007 UAM Czech Republic s.r.o. Limuzská 2110/8 100 00 Praha 10 Strašnice A. Smlouva o poskytování internetových služeb 1. Smluvní strany Smluvními stranami je firma

Více

Moje Cisco Nejčastější dotazy

Moje Cisco Nejčastější dotazy 1. Co je Moje Cisco? Moje Cisco umožňuje mobilní, přizpůsobitelné zobrazení vašich oblíbených informací na webu Cisco.com. 2. Jak otevřít stránku Moje Cisco? Moje Cisco lze otevřít dvěma způsoby: Rozbalovací

Více

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE WEBOWÉ STRÁNKY TŘÍD KAMIL POPELKA ZÁVĚREČNÁ MATURITNÍ PRÁCE BRNO 2011 Prohlášení Prohlašuji, že maturitní práce je mým původním autorským dílem, které

Více

Evidence požadavků uživatelů bytů a nebytových prostor

Evidence požadavků uživatelů bytů a nebytových prostor Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový

Více

Využití OOP v praxi -- Knihovna PHP -- Interval.cz

Využití OOP v praxi -- Knihovna PHP -- Interval.cz Page 1 of 6 Knihovna PHP Využití OOP v praxi Po dlouhé teorii přichází na řadu praxe. V následujícím textu si vysvětlíme možnosti přístupu k databázi pomocí různých vzorů objektově orientovaného programování

Více

Modul msender message Sender. Nápověda

Modul msender message Sender. Nápověda Modul msender message Sender Nápověda msender je rozšiřujícím doplňkem systému Money S5 a vytváří pro informační systémy Money bránu do světa SMS zpráv a E-mailové obchodní komunikace. Modul je plně integrován

Více

Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz

Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz Na výše uvedené URL adrese je umístěno jednoduché online rozhraní pro evidenci reklamací tabletů a příslušenství Wooky. Evidenční rozhraní

Více

17. července 2005 15:51 z moravec@yahoo.com http://www.z-moravec.net/

17. července 2005 15:51 z moravec@yahoo.com http://www.z-moravec.net/ 17. července 2005 15:51 z moravec@yahoo.com http://www.z-moravec.net/ Úvod 1 Úvod Nedávno jsem zveřejnil návod na vytvoření návštěvní knihy bez nutnosti použít databázi. To je výhodné tehdy, kdy na serveru

Více

INFORMACE O NAKLÁDÁNÍ S OSOBNÍMI ÚDAJI KLIENTŮ YIT STAVO

INFORMACE O NAKLÁDÁNÍ S OSOBNÍMI ÚDAJI KLIENTŮ YIT STAVO INFORMACE O NAKLÁDÁNÍ S OSOBNÍMI ÚDAJI KLIENTŮ YIT STAVO Vážení, dovolujeme si Vás touto cestou informovat, že společnost YIT Stavo s.r.o. (dále jen YIT Stavo ) shromažďuje, zpracovává a uchovává některé

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Jan Forman Manuál 30.5.2013. CLASSIFICATIO N: public / veřejný dokument IDE NTIFICATIO N N U MBER: 0000000000001 AUTH OR:

Jan Forman Manuál 30.5.2013. CLASSIFICATIO N: public / veřejný dokument IDE NTIFICATIO N N U MBER: 0000000000001 AUTH OR: CLASSIFICATIO N: public / veřejný dokument TITLE: Manuál k webovému rozhraní hostingu P ub l i c URL: http://janforman.org/files/webhosting.pdf OFFICE NAME AND ADDRESS: --- IDE NTIFICATIO N N U MBER: 0000000000001

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] popis platebních metod PRSMS a průběhu platby verze 17 / 29.2.2012 1 Obsah 1 Přehled platebních metod 3 1.1 Premium rate SMS 3 1.2 Premium rate SMS [erotický obsah] 3

Více

Novinky v registru domén a mojeid. Jaromír Talíř jaromir.talir@nic.cz 21.05.2013

Novinky v registru domén a mojeid. Jaromír Talíř jaromir.talir@nic.cz 21.05.2013 Novinky v registru domén a mojeid Jaromír Talíř jaromir.talir@nic.cz 21.05.2013 Obsah Skrývání adresy v WHOIS Slučování duplicitních kontaktů Novinky v mojeid Doménový prohlížeč Skrývání adresy v WHOIS

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] popis platebních metod Bankovní převod a Poštovní poukázka v ČR a SR a průběhu platby verze 19 / 29.2.2012 1 Obsah 1 Přehled platebních metod 3 1.1 Bankovní převod v

Více

Aplikace pro elektronicke odesla nı da vky Listu o prohlı dce zemr ele ho a dals ı ch da vek do NZIS.

Aplikace pro elektronicke odesla nı da vky Listu o prohlı dce zemr ele ho a dals ı ch da vek do NZIS. Aplikace pro elektronicke odesla nı da vky Listu o prohlı dce zemr ele ho a dals ı ch da vek do NZIS. ÚVOD Od 1. 1. 2016 vejde v platnost novela vyhlášky č. 297/2012 Sb., o náležitostech Listu o prohlídce

Více

24 Uživatelské výběry

24 Uživatelské výběry 24 Uživatelské výběry Uživatelský modul Uživatelské výběry slouží k vytváření, správě a následnému používání tématicky seskupených osob a organizací včetně jejich kontaktních údajů. Modul umožňuje hromadnou

Více

DNS, DHCP DNS, Richard Biječek

DNS, DHCP DNS, Richard Biječek DNS, DHCP Richard Biječek DNS (Domain Name System) Překlady názvů hostname Informace o službách (např. mail servery) Další služby (zpětné překlady, rozložení zátěže) Hlavní prvky DNS: DNS server(y) DNS

Více

Jednorázová hesla pro zvýšení bezpečnosti vzdáleného přístupu mobilních uživatelů

Jednorázová hesla pro zvýšení bezpečnosti vzdáleného přístupu mobilních uživatelů Jednorázová hesla pro zvýšení bezpečnosti vzdáleného přístupu mobilních uživatelů Jedním z řešení bezpečného vzdáleného přístupu mobilních uživatelů k firemnímu informačnímu systému je použití technologie

Více