Avatar
Jakub Šárník:

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. ledna 21:25
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Jakub Šárník
Martin Dráb:

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. ledna 23:20
2 + 2 = 5 for extremely large values of 2
Avatar
Odpovídá na Martin Dráb
Jakub Šárník:

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. ledna 23:31
Avatar
Jakub Šárník:

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. ledna 20:48
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Jakub Šárník
Martin Dráb:

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 19. ledna 22:51
Nahoru Odpovědět 19. ledna 22:50
2 + 2 = 5 for extremely large values of 2
Avatar
Odpovídá na Martin Dráb
Jakub Šárník:

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  +1 20. ledna 10:47
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.