Ještě před tím, než začnu psát tento článek, chtěl bych upozornit, že dnes se více než kdy jindy bude jednat o můj osobní názor na věc a jsem si jist, že se najde mnoho lidí, kteří se mnou nebudou souhlasit. Nicméně tak to cítím a tak to i napíšu….
Není to tak dlouho, co jsme se s Jirdou jako tvůrcem www.on-game.cz (dále jen OG) zabývali myšlenkou, jak rozšířit portfolio služeb tak, aby byla zajímavá nejen pro čtenáře různých článků a některé druhy hráčů ale pro všechny hráče a nejlépe i pro hry samotné.
Plný dojmů z několika článků jsem přišel tehdy s návrhem, zavést do OG něco jako centrální registr hráčů, kde by bylo možné hledat hráče nejen podle loginu a zjišťovat jaké hry hrají a pod jakým loginem, případně jejich historii, ale také hledat hráče podle hry. O dalších funkcích tohoto systému bych ze strategických důvodů v této chvíli raději pomlčel.
Shodou okolností jsem se dnes od jednoho z čtenářů OG dozvěděl o systému OnCen tedy centrále loginů online her. Jak by řekl Vinetou: „Mé srdce zaplesalo.“ Byl jsem rád, že někdo jiný se rozhodl tuto myšlenku implementovat a tak jsem neváhal zavítat na web.
Abych upřesnil myšlenku projektu OnCen. Jedná se o centrální databázi loginů pro online hry. Což samo o sobě přináší mnoho a mnoho možných funkcí. Registrací do tohoto systému by měl získat hráč přístup do všech registrovaných her, přirozeně po absolvování některých těch „úřednických procedur“. Ale pak přišlo mé zklamání, které se pokusím vysvětlit.
Systém OnCen vyžaduje splnění několika pravidel, což samo o sobě je logický požadavek, nicméně….
Na hrách musí být nastavena maximální nečinnost hráče na maximálně 30 minut
a zároveň
Centrála sama odhlašuje všechny po jedné hodině. I pokud hráč na hře sám klikne po půl hodině, tedy projeví aktivitu a nebyl ještě odhlášen, musí být odhlášen, na centrále se tak totiž již mohlo stát.
V pořádku, omezení délky session je i z bezpečnostního hlediska dobrá věc, ale co když… aplikace je postavena na tom, že se zrovna v tomhle od ostatních liší?
Každých (maximálně) 5 minut (případně při každém kliku hráče, pokud hra nemá k dispozici cron) musí být spouštěno ověření neaktivních a ti pak odhlášeni (i na centrále).
Sledoval někdo z autorů provoz a zátěž na jejich straně? Zabýval se někdo dopadem na běh „klientských“ aplikací? Možné problémy síťové komunikace nepřichází jen se šířkou dostupné linky ale také s čekáním při navazování spojení. Pokud tedy na hře jsou řekněme stovky až tisíce uživatelů, může být tento požadavek velkým břemenem pro aplikaci samotnou.
Hry si musí od 5 minut spouštět script, který pošle na centrálu aktivitu přihlášených hráčů (čas posledního kliku. Pokud nemají cron, nechť si u každého hráče zvlášť logují čas posledního odeslání aktivity a při jeho dalším kliku, pokud už uplynulo alespoň 10 minut od posledního odeslání aktivace ji odešlou. 2)
Zde opět narážíme na výkonové varování, jednak musíme registrovat poslední aktivitu hráče, jednak je musíme pravidelně odesílat na centrální server, jednak problém kolem synchronizace obou systémů.
… nyní mi dovolte, abych celou myšlenku lehce přebudoval.
Je skutečně důležité na centrále vědět, kdy hráč někam kliknul? Ve skutečnosti nás zajímají dva časové okamžiky a to okamžik přihlášení a okamžik odhlášení. Cokoliv mezi tím je pro nás víceméně zbytečný provoz. Z hlediska bezpečnosti nás mohou zajímat některé parametry zjistitelné o uživateli a to IP adresa a další drobnosti. Ty se zpravidla nemění a pokud ano, měla by to být klientská aplikace, která nás o tom bude informovat, ovšem pouze o změnách. Bezpečnostní prvky by si ale měla každá aplikace hlídat sama, je to přeci ona, se kterou uživatel komunikuje a je to tedy ona, kdo je v potenciálním nebezpečí. A pokud by náš systém měl sloužit jako autentikační autorita, pak není jeho cílem bránit aplikaci ale pouze centrálně spravovat autentikační informace. Další otázkou jsou samotné cíle projektu.
Jako velmi velmi nešťastná mi přijde myšlenka požadovat změny právě v oné aplikační bezpečnosti. Přeci jen klientské aplikace se sice vůči našemu systému chovají jako klienti ale ve skutečnosti jsou to serverová řešení vyznačující se komplexností a vlastní logikou a chtít do tohoto zasáhnout z role třetí strany hodnotím jako silně troufalé. Představte si, že existuje bankovní ústav pro zjednodušení Genesis Bank (GB) a existuje uživatel Lojza Tomásek (LT) z Velké Malé nad Ztracenou, který by si každý den chtěl stahovat kurzy měn aby je mohl na svém portálu zobrazovat. GB jako dárek pro své klienty nabízí datový export těchto dat ale jen v XML (z technologických důvodů a předpokladů, které nebudeme dále rozebírat). Náš LT oproti tomu umí zpracovávat pouze plain text data. Představte si, že LT odešle na GB požadavek, aby speciálně pro něj úplně změnili formát a strukturu dat. (odhlédněme od skutečnosti jak jednoduché je řešení tohoto konkrétního zjednodušeného příkladu) Osobně si nemyslím, že by GB nechala přepsat export dat jen pro to, aby vyhověla jedinému uživateli, natož aby na přání jiného uživatele úplně měnila platformu jen pro to, že on neumí jejich data zpracovat. Zde bohužel vidíme u OnCen stejné chování. Chtě nechtě OnCen je stále jen modul třetí strany, který je na aplikaci „navěšen“ a z tohoto titulu dle mého názoru nemá právo požadovat kritické zásahy do aplikace, kterými jsou jakékoliv zásahy do bezpečnostních modulů a nastavení.
Zde se bohužel autoři OnCen, dle mého názoru, dopustili zásadní chyby, která jim samotným brzdí rozšíření tohoto skvělého projektu. Tvůrci her nebudou chtít měnit specifika svých projektů jen proto aby se připojili do nějakého jiného projektu, tím méně čím větší budou požadavky na zapojení se. Narážíme zde na přirozenou lenost a neochotu cokoliv měnit, tím více pokud se jedná o rozběhnutý a fungující projekt. Jednak narážíme na přirozenou paranoiu lidí v IT (systémáci jistě souhlasí :o) ) a konečně narážíme na hrozící výkonové problémy. Jako tvůrce jedné z online her v této chvíli říkám ne, nikoliv však vůči samotné myšlence ale vůči implementaci a právě požadavkům. Obávám se že obdobné rozhodnutí padlo již u dalších … a říkám si, že to je škoda.
V konečné fázi sjednocení loginů pro několik portálů je praxe, která v obchodním světě není ničím novým a troufám si řici ani tak ojedinělým, jak se nám na první pohled zdálo. Ostatně jmenujme Microsoft, Gogole, Seznam… předpokládám, že dál pokračovat nemusím.
Na závěr bych rád řekl, že přes ostrá slova, která jsem zde napsal, považuji tento projekt za velmi přínosný a zajímavý. A přes několik úkroků stranou stále myslím, že má velmi dobře vykročeno a má potenciál i příležitost stát se skutečnou centrální autentikační autoritou. Proto jeho autorům držím pěsti.



