Nové výhodné předplatné namísto kreditů je tu! Více informací. Upravili jsme také naše provozní podmínky.
NOVINKA: Staň se datovým analytikem a získej jistotu práce, lepší plat a nové kariérní možnosti. Více informací:
Avatar
Neaktivní uživatel
Člen
Avatar
Neaktivní uživatel:17.1.2016 21:25

Jsem členem menší skupiny lidí vytvářející jeden webový projekt, který byl z počátku vytvářen pouze v Djangu. Živelnost vývoje a další problémy nás však přiměly přemýšlet o novém návrhu a přepsání velké části kódu. Já osobně nejsem tak zkušený ve vývoji webových aplikací, ale myslím, že by bylo mnohem jednodušší a přehlednější, kdyby v Djangu zůstala jen serverová část komunikující s databází a fungující jako API a webový klient by byl napsán pouze v HTML+CSS+JS (s jQuery, Angularem a/nebo dalšíma věcma). Neslo by to i tu výhodu, že by se daly napsat další klienty například pro desktop v C# a tak dále.
Problém, který mě těď ale napadl (jak jsem řekl, nejsem tak zkušený v tomto), je způsob přihlašování uživatelů a správa práv. Jak se tyto věci dnes při tomto moderním způsobu návrhu (oddělení frontendu a backendu) řeší?

Odpovědět
17.1.2016 21:25
Neaktivní uživatelský účet
Avatar
Martin Dráb
Tvůrce
Avatar
Odpovídá na Neaktivní uživatel
Martin Dráb:17.1.2016 23:20

Webovky sice nedělám, ale obecně je to u klient/server architektury tak, že bezpečnost (autentizaci, autorizaci) musíš řešit na serveru. Musíš předpokládat, že někdo <dpolň vhodné přídavné jméno> se pokusí přistupovat přímo k serveru (přes API), a tak klientský kód úplně obejde.

Tudíž bych autentizaci i autorizaci řešil přes API (tzn. serveru by se odeslaly požadované přihlašovací údaje či rozumná identifikace uživatele a on by sám rozhodl, zda-li přihlášení či jinou operaci provede či ne).

Stejně budete muset přemýšlet nad tím, kolik toho bude umět server a kolik klienti (tzn. kdo bude tlustý a kdo tenký). Od toho se pak odvíjí různé výhody a problémy.

Nahoru Odpovědět
17.1.2016 23:20
2 + 2 = 5 for extremely large values of 2
Avatar
Neaktivní uživatel
Člen
Avatar
Odpovídá na Martin Dráb
Neaktivní uživatel:17.1.2016 23:31

Zamýšlím to jako tenký server a tlustí klienti. Samozřejmě že mě nenapadlo řešit autentizační a autorizační logiku v javascriptu na klientu :-D, jde mě spíš o to, jak bezpečně odeslat údaje a přijmou nějaký session id nebo tak

Nahoru Odpovědět
17.1.2016 23:31
Neaktivní uživatelský účet
Avatar
Neaktivní uživatel
Člen
Avatar
Neaktivní uživatel:19.1.2016 20:48

BUMP a chtěl jsem ještě něco doplnit:
Možná, že backend bude nakonec realizován jako ASP.NET Web API 2 a frontend použije AngularJS nebo ekvivalent. Jak se vůbec tato moderní architektura jmenuje a jak dnes konkrétně v tomto případě autorizace a autentizace probíhá?

Nahoru Odpovědět
19.1.2016 20:48
Neaktivní uživatelský účet
Avatar
Martin Dráb
Tvůrce
Avatar
Odpovídá na Neaktivní uživatel
Martin Dráb:19.1.2016 22:50

Pokud bych tyhle bezpečnostní věci měl dělat já, člověk neznalý věcí webových, tak by to bylo asi následovně:

Při autentizaci by klient na server poslal přihlašovací údaje, samozřejmě zašifrované veřejným klíčem od serveru (SSL to pořeší). Server by v případě úspěšné autentizace vrátil to, čemu říkáš session ID, což bude pro klienta taková zkratka, jak serveru prokázat, že se jedná o daného uživatele (aniž by bylo nutné znovu posílat přihlašovací údaje). Samozřejmě, session ID bude muset putovat v zašifrované podobě.

Pak klient může s každým požadavkem na server posílat ono session ID, čímž serveru sdělí identitu uživatele. Takže server může rozhodnout, zda-li na příslušnou operaci má uživatel dost oprávnění.

Pokud by převažoval objektový přístup (klient si vyžádá přístup k entitám, se kterými pak pracuje), můžeš koncept session ID rozšířit tak, že klient na počátku práce s entitou serveru sdělí, že s ní chce pracovat a jaké operace s ní bude cca provádět. Server mu vystaví speciální ID (v žargonu Windows kernelu a systému se tomu říká handle), která opravňuje daného uživatele provádět s entitou určité operace. Pak stačí kontrolovat, že handle předané při žádost o provedení operace s entitou má dovoleno tuto operaci provést a nemusí se kontrolovat přímo oprávnění uživatele (to se udělalo při vydávání handle).

To je flexibilnější přístup, ale je otázka, zda-li se ti vyplatí. Pak se musíš rozhodnout, jak moc budou handle unikátní (jestli v rámci jednoho uživatele, nebo úplně všechna) a po jakém časte tyhle všechny identifikátory na serveru zrušit, pokud to klient explicitně neudělá.

EDIT: Ale vsadím se, že v těch různých knihovnách tenhle problém bude nějak řešen, protože potká asi spoustu lidí. Takže spíš by bylo lepší nastudovat ty knihovny.

Editováno
Nahoru Odpovědět
19.1.2016 22:50
2 + 2 = 5 for extremely large values of 2
Avatar
Neaktivní uživatel
Člen
Avatar
Odpovídá na Martin Dráb
Neaktivní uživatel:20.1.2016 10:47

Ano, to s tím session ID mě napadlo, ale ty handle zní taky zajímavě. Otázka je, jestli jsou potřeba. Každopádně to nastuduju, jestli jsou takové knihovny (to snad jsou) :-)

Nahoru Odpovědět
20.1.2016 10:47
Neaktivní uživatelský účet
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 6 zpráv z 6.