středa 17. srpna 2005

Autentizační token jako součást URL

Docela složitě jsem vybíral název pro tenhle post a tak bude lepší, když přejdu přímo k problému, který si osvětlíme na příkladu. Dejme tomu, že máme komentářový systém a chceme, aby měl každý pisatel možnost svůj komentář zpětně změnit. Protože nechceme, aby si pisatel musel přihlašovat resp. někde registrovat, jsme postaveni před problém jak uživatele autentifikovat.

Možné scénáře

Heslo ke každému komentáři
  1. Pisatel vytvoří komentář a zadá k němu heslo (případně se mu vygeneruje)
  2. Při pokusu o editaci je uživatel nucen zadat heslo

Nevýhoda tohoto řešení je zřejmá, pisatel si musí pamatovat heslo ke každému komentáři, samozřejmě pokud si nebude všude volit stejné heslo. Tenhle systém by šlo modifikovat následujícím způsobem.

  1. Pisatel vytvoří komentář
  2. Pisatel obdrží URL pro editaci komentáře a to včetně hesla
  3. Při pokusu o editaci použije tuto URL

URL resp. GET požadavek by byl samozřejmě přes HTTPS např. https://server/editComment.foo?commentId=1&pass=bflmpsvz. Bezpečnost přenosu zaručena pomocí HTTPS, ale stejně je heslo volně viditelné v adresním řádku prohlížeče. Chtělo by se to zbavit hesla v URL.

Část URL jako autentizační token
  1. Pisatel vytvoří komentář
  2. Pisatel obdrží URL s autentizačním tokenem pro editaci
  3. Při pokusu o editaci uživatel použije tuto URL

Opět vycházíme z toho, že vlastní GET požadavek by šel bezpečnou cestou. Fígl řešení spočívá v unikátnosti dané URL a v časové náročnosti pro její hacknutí. Unikátnost vygenerované URL je zaručena serverem, který může postupovat například takto.

  1. Server vezme identifikátor daného komentáře
  2. Identifikátor komentáře je upraven pomocí konstanty (např. prohození prvního znaku s posledním)
  3. Upravený identifikátor se prožene přes symetrickou šifru
  4. Zašifrovaný identifikátor je pomocí BASE64 vložen do URL

Výsledná URL pak vypadá např. takhle https://server/editComment.foo?hoo=U9j5SVoEynNKsj4f1XQLVQ. Při požadavku na editaci komentáře je postup opačný. Výhoda spočívá v tom, že hloupoučkou změnou URL se ničeho nedosáhne a pro případné prolomení bude muset použít brute force. Nevýhoda je ta, že pisatel si takto vytvořenou URL nezapamatuje, stejně jako si jí ovšem nezapamatuje např. kolemjdoucí v internetové kavárně.

pondělí 15. srpna 2005

FastRPC - binární XML-RPC

Jak informoval Chose, vývojáři společnosti Seznam.cz rozšířili open source rodinu o další projekt. FastRPC je XML-RPC, které používá pro přenos data serializovaná do binární podoby.

Kouzlo FastRPc by mělo ležet právě v onom úsporném binárním formátu, jak píše Chose

...protokol FastRPC, který je nejvíce užitečný u vysoko zátěžových aplikací, které vyžadují vysoký výkon, rychlost a minimální přenos zbytečných dat. Toto je možné díky tomu, že FastRPC je vlastně binární verze klasického XML-RPC.

Toto tvrzení zdá se mi poněkud diskutabilní. Troufám si tvrdit, že XML-RPC je sám o sobě lightweight protokol, který žádné problémy s rychlostí nezpůsobuje. Změnou plain textu za binární formu se sice dosáhne úspory v datovém přenosu, ale může dojít k binárním nekompatibilitám při serializaci/deserializaci na heterogenních systémech. Právě z důvodů interoperability se preferuje XML resp. plain text, alespoň dokud tu nebude standard v podobě binárního XML viz Akta X 0309.

Je otázkou, pokud bylo motivem ušetření datového přenosu, proč se nepoužili standardní prostředky, které nabízí HTTP protokol. Pomocí komprese, kterou je možno v rámci HTTP použít, by šlo dosáhnout velice dobré úspory co do velikosti přenášených dat. Bylo by velice zajímavé porovnat FastRPC oproti komprimovanému XML-RPC. Nadto by mě zajímalo jaké je "výkonový nárůst" binárního XML-RPC oproti klasickému XML-RPC.