[vpsFree.cz: community-list] [vpsFree.cz: news-list] vpsAdmin API a další směr vývoje
Ján Raska
raskaj at gmail.com
Thu May 29 01:14:15 CEST 2014
Ohladom tej session, odhliadnuc od toho, ze je to bezny stateful system, ktory vie spravit vacsina frameworkov a netreba ho kodit manualne, a taktiez odhliadnuc od toho ze je to, ako pisal snajpa, zbytocna komplikacia, tak ono si to pyta pruser. A sice, pruser zvany CSRF resp. XSRF (cross-site request forgery).
Jeden priklad to krasne vysvetli: VpsFree ma takto ako si pisal nakodenu autentifikaciu k API. Chcem Ta nasrat, prip. sa pobavit na Tvoj ucet a nejako som sa dopracoval k informacii ake je cislo Tvojej VPS (resp. nemusim, rovno vyskusam cisla od 1 po niekolko tisic, tak vela ich zas nie je a raz sa urcite trafim :) ). Vytvorim shortcut https://bit.ly/xyz za ktorym sa skryva https://api.vpsfree.cz/v1/vpses/:999?action=stop a dokopem Ta k tomu aby si na to klikol (napr. poslem Ti spravu “Tuto je super clanok o tom, preco stateful API nie je dobre: https://bit.ly/xyz “), alebo, este lepsie, aby to vyzeralo doveryhodnejsie, urobim si blog, kde ten clanok naozaj napisem a vlozim do toho aj <img src=“https://api.vpsfree.cz/v1/vpses/:999?action=stop” /> a poslem neskratenu url, aby si ma nepodozrieval, zvysok roboty urobi browser za Teba ked sa bude snazit vyrenderovat ten obrazok. Pokial mas este neexpirovanu session na vpsfree.cz, tak som Ti prave vypol VPSku :) Lebo ten cookie browser odosle automaticky. Pekne, nie? :)
Pri stateless api sa Ti toto nemoze stat. A kludne si aj ten token mozes ulozit do cookie, ale pod podmienkou, ze ten cookie pouzijes iba ako storage (pouzivam pri browseroch ktore nepodporuju local storage). Ten cookie sa sice odosle, ale server ho ignoruje, pre vykonanie API potrebuje mat token v Authorization header-i. A toto uz tymto sposobom nesfalsujem, lebo ja sa k tym udajom neviem dostat, ja iba zneuzivam fakt, ze tie data browser posiela automaticky s kazdym requestom. Token sice na rozdiel od cookie neuchranim pred pristupom Javascriptu (cookie mozem nastavit ako HttpOnly) a teda je to nachylnejsie na XSS, avsak proti XSS sa da branit velmi lahko, zabranenim injectovaniu. Ale proti XSRF sa realne pri stateful cookie/session based autentifikacii nemas sancu ubranit. Request totiz vykona Tvoj browser, na serveri nemas ako odlisit takyto podvrhnuty request od skutocneho, sedi uplne vsetko, cookie, user-agent, IP, atd.
A teraz ceresnicka na torte, zeby browser automaticky doplnal pri http-basic aj ten Authorization header? A navyse session pri http-basic expiruje az zavretim browseru? Takze snajpa, toto nie je o revolucii, toto je o relativne elementarnej bezpecnosti, myslim ze nik z nas nema o vyssie popisane vypnutie VPSky zaujem :)
Inak co sa tyka API, vrele odporucam knihu RESTful Web APIs (O’Reilly, http://shop.oreilly.com/product/0636920028468.do), tam su popisane aj dalsie veci, ako napr. ze nie je uplne vhodne pouzit cisty JSON, nakolko ten nema specialy typ na linky/url-ky a teda take API nemoze byt RESTful, lebo nesplna zakladnu podmienku - nema hypermedia. Pocitac totiz nerozumie co znamena “url”: “….”, pre PC to je iba dalsi field typu String s nazvom “url”. Tym padom sa znacne komplikuje automatizacia a prakticky nie je mozny scanning celeho api, taketo api realne nie je self-descriptive. Zial, toto je este iba v plienkach a standardy neexistuju, ja som to riskol s draftom HAL+JSON (http://tools.ietf.org/html/draft-kelly-json-hal-06 resp. http://stateless.co/hal_specification.html).
Ale uz sa asi hram na prilis mudreho :)
Jano
On 22 May 2014, at 10:18, Peter Šufliarsky <sufliarskyp at gmail.com> wrote:
> Ahojte,
>
> v poslednej dobre intenzívne využívam jedno REST-ové API, tak pridávam dva postrehy, o ktorých si myslím, že by mohli byť zaujímavé.
>
> Súhlasím s tým prihlasovaním. V mojom prípade prihlasovanie riešime tak, že máme authentication request, v ktorom sa odošlú prihlasovacie údaje. Po úspešnom prihlásení server vytvorí session a v hlavičke odpovede odošle okrem iného Set-Cookie SESSIONID=xxx, kde xxx je nejaký unikátny kľúč. Ten sa potom odosiela v hlavičke ostatných requestov a server podľa toho overí užívateľa. Platnosť session ID vyprší po 30 minutách nečinnosti alebo po odoslaní logout requestu.
>
> Operácie typu start/stop/restart a podobne by som riešil takto: POST /v1/vpses/:vps_id?action=start Je to asi len kozmetická zmena, ale mne to pripadá byť trochu viac logické. start/stop/restart nereprezentujú žiadne resources na serveri.
>
> Peťo
>
>
>
> 2014-05-22 9:48 GMT+02:00 René Klačan <rene.klacan at gmail.com>:
> Ahojte,
>
> nebolo jednoduchsie a casovo uspornejsie pouzit uz nejaky existujuci API framework? Z mojho pohladu by to mohlo usetrit vela casu. Napriklad https://github.com/intridea/grape . Ci si myslite, ze poziadavky su natolko specificke, ze by to podobna kniznica efektivne nepokryla a bolo by ju nutne az nezmyselne ohybat?
>
> Ale inak skvela praca, velmi pekne napisane a tiez velmi ocenujem, ze to je v Ruby! Len by som vytkol to, ze tam nevidim testy.
>
> Rene
>
>
> 2014-05-21 22:10 GMT+02:00 Pavel Snajdr <snajpa at snajpa.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Ahoj,
>
> posilat porad username+password a nemit rozliseni mezi API pristupem a
> UI pristupem je smrt, natoz to chtit nejak potom auditovat, totalne
> nemozne - takze to je jedna z veci, co se bude resit dal, vime o tom.
>
> Neco na ten, jak rikas, je urcite v planu, ono to jenom nejde delat
> jako revoluci "vsechno najednou", jelikoz prerodit vpsAdmin za behu v
> neco min srackoidniho (zdravim sam sebe o 5 let v minulosti) to neni
> task na par tydnu a obzvlast kdyz se to clovek rozhodne udelat poradne
> a jeste to chce udelat recyklovatelne.
>
> Proto jsme vymysleli jak co nejvic ty prace ohledne API a tak
> automatizovat uz samotnym napsanim toho kodu urcitym stylem, aby se
> napsal jenom jednou a nebylo potreba udrzovat 228342934 veci okolo
> jako napr. dokumentace a kvadrilion ruznych klientu pro triliardu
> platform :))
>
> Aither prerodil tenhle muj napad v HaveAPI, coz vypada jako uplne
> super vec, na kterou jsem celou dobu cekal.
> Uz nejakou chvili se zabyvam s ruznymi lidmi automatizaci ruznych
> low-level procesu (mluvim o low-level vecech z pohledu provozovatele
> byznysu online, tzn. nastaveni OS, runtime jazyka, DB...) a presne
> nejaka takovahle moznost jak vybavit uzavrene komplexni prostredi
> jasne popsanym strukturovanym rozhrani na praci s nim, to mi presne
> chybelo.
>
> Proto bych chtel, jestli mate kdo ted cas, fakt na to mrknete, jestli
> jste meli potrebu kdy tvorit nejaky APIcka pro neco, tohle je uplne o
> necem jinym, je to holt vyzdimana koncentrovana bolest pri psani API
> pretavena v lek :))
>
> No a celej duvod, proc jsem se s Aitherem dohodnul, ze to announcne uz
> ted, kdyz se uci na statnice, je aby byl prostor na feedback.
>
> Takze kdo jste kdy delal HTTP API pro neco, kouknete na to a dejte
> vedet. Dik!
>
> S pozdravem
>
> Pavel Snajdr
>
> +421 948 816 186 | +420 720 107 791 | 110-010-956
> CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE
> http://relbit.com | http://vpsfree.cz | https://www.redhat.com
>
> On 05/21/2014 08:20 PM, Ján Raska wrote:
> > Ahoj,
> >
> > super napad. Akurat mam malu vyhradu voci autentifikacii, moderne
> > RESTful APIs sa dnes vacsinou robia stateless s pouzitim tokenu,
> > ktory sa zasiela vramci Authentication headeru. S tym ze okrem
> > temporary tokenu je aj moznost zisat long-term token (bez
> > expiracie), alebo este lepsie short-term token spolu s refresh
> > tokenom (refresh token bezpecne ulozim, komunikujem so short term
> > tokenom a ked vyprsi, tak pomocou refresh tokenu urobim reissue). V
> > podstate na podobnom principe pracuje OAuth 2.0, ale na nieco
> > taketo je z mojich skusenosti jednoduchsie nakodit nieco vlastne
> > nez implementovat cely OAuth (pokial samozrejme nepouzijem hotovu
> > libku :) ).
> >
> > Vyhoda takehoto API je, ze sa potom k tomu daju napisat mobilne
> > appky, do ktorych sa prihlasis raz a oni si token ulozia do device
> > DB.
> >
> > Jano
> >
> > On 20 May 2014, at 19:01, Jakub Skokan <jakub.skokan at havefun.cz
> > <mailto:jakub.skokan at havefun.cz>> wrote:
> >
> >> Zdravím,
> >>
> >> na adrese https://api.vpsfree.cz je k dispozici vývojová verze
> >> vpsAdmin API. Je to ve stavu, kdy to funguje, ale není to
> >> doladěné a nemá to všechny funkce.
> >>
> >> Při vývoji vzniknul framework HaveAPI [1], který naše API
> >> využívá. Jedná se o framework na tvorbu sebepopisujících se
> >> RESTful API.
> >>
> >> Sebepopisující se API odpovídá na HTTP metodu OPTIONS a vrací
> >> JSON obsahující seznam dostupných verzí API, objektů, akcí,
> >> jejich vstupních/výstupních parametrů, popis, validaci, ukázku
> >> použítí, apod. Díky této vlastnosti lze vytvořit klienta, který
> >> dokáže komunikovat s jakýmkoli API, které je postavené nad
> >> HaveAPI. Změny v API se okamžitě projeví ve všech klientech,
> >> atd.
> >>
> >> Dokumentace API: - Automaticky generovaná frameworkem na
> >> https://api.vpsfree.cz
> >>
> >> Co to zatím umí: - Vytvoření a smazání playground VPS, - seznam
> >> vlastních VPS, start, stop, restart, změna hesla, přeinstalace, -
> >> výpis konfigurace VPS, - seznam IP adres VPS, - seznam dostupných
> >> dstribucí (nutné k vytvoření VPS).
> >>
> >> Připravení klienti: - CLI a klient v Ruby (>= 2.0) [2], který
> >> také existuje v obecné formě (pro jakékoliv API, rozdíl je pouze
> >> ve jménu a výchozí URL) [3], - PHP klient [4] a jeho obecná forma
> >> [5].
> >>
> >> Návody na instalaci a použití jednotlivých klientů jsou na
> >> přiložených odkazech.
> >>
> >> Aktivita je vítána. Hodilo by se, kdyby se našlo pár lidí, co by
> >> udělali klienta ve svém oblíbeném jazyce. Nejvíc by se nám hodil
> >> alespoň proof-of-concept v JS, abychom si ověřili, že je možné
> >> udělat UI kompletně v HTML5 & JS, já už na to aktuálně nemám
> >> čas.
> >>
> >> Pokud nenarazíme na nějaké větší problémy, aplikační logika
> >> vpsAdminu se bude postupně přesouvat z webového rozhraní do
> >> tohoto API. Současně se z vpsAdminu pomalu bude stávat nezávislý
> >> projekt na vpsFree.cz, aby jeho použití nebylo limitováno naším
> >> sdružením a šel nasadit i jinde.
> >>
> >> Do budoucna se počítá s tím, že přes API půjde hýbat s parametry
> >> VPS a člen si bude moci rozdělit přidělené prostředky mezi více
> >> VPS jak se mu zlíbí (v rozumných mantinelech).
> >>
> >> Rozhodli jsme se to spustit a oznámit co nejdříve, i když
> >> nekompletní, aby se koncept otestoval v praxi. Budu rád za
> >> jakoukoliv zpětnou vazbu, nápady či připomínky.
> >>
> >> [1] https://github.com/vpsfreecz/haveapi
> >>
> >> [2] https://github.com/vpsfreecz/vpsfree-client
> >>
> >> [3] https://github.com/vpsfreecz/haveapi-client
> >>
> >> [4] https://github.com/vpsfreecz/haveapi-client-php/tree/vpsfree
> >>
> >> [5] https://github.com/vpsfreecz/haveapi-client-php -- S
> >> pozdravem
> >>
> >> Jakub Skokan _______________________________________________
> >> News-list mailing list News-list at lists.vpsfree.cz
> >> <mailto:News-list at lists.vpsfree.cz>
> >> http://lists.vpsfree.cz/listinfo/news-list
> >
> >
> >
> > _______________________________________________ Community-list
> > mailing list Community-list at lists.vpsfree.cz
> > http://lists.vpsfree.cz/listinfo/community-list
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlN9CEsACgkQMBKdi9lkZ6p1UgD9FhUz15ApUnlTqufJgATy2BCa
> QPkScmJTxfU/gcDGynAA+wavOPBtamMxqOjiRsuKHt4SUYPLtJSuEq2wB8VrH8e/
> =jIPF
> -----END PGP SIGNATURE-----
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20140529/59927690/attachment-0002.html>
More information about the Community-list
mailing list