Máte někdo zkušenosti s řešením oprávnění na úrovni desktopové aplikace? Mám tím na mysli věci typu "tento uživatel smí toto tisknout", či "tato skupina smí tento objekt modifikovat, ale ne smazat" atd.

Zatím jsem to řešil tak, že při přihlašování do aplikace byl uživatel ověřen proti databázi (MSSQL) a pak jsem mu přiděloval práva víceméně ručním způsobem. Systém přihlašování a oprávnění mám tedy zčásti založen na uživatelích a skupinách v MSSQL a zčásti to prasím. Toto mi přestává stačit a začíná přerůstat přes hlavu.

Nevíte o nějakém udělátku či mini-frameworku, který by s tím to pomohl? Tzn. jde mi o:

* možnost mít uživatele a skupiny
* možnost nastavovat práva uživatelům a skupinám
* možnost to nějak jednoduše spravovat
* možnost s tím nějak jednoduše pracovat z kódu

Díky za tipy!

 
           [Odpovědět]

Ověřen proti databázi? Proboha snad nepřipojujete klienty přímo do databáze! Běžně se to dělá tak, že do databáze se připojuje pouze aplikační server jedním jediným uživatelským účtem a autentizaci a autorizaci řeší aplikační server (který také spravuje tyto uživatelské účty a jejich oprávnění), říká se tomu třívrstvá architektura.

Dá to sice celkem práci takový mechanizmus vytvořit, ale .NET Framework k tomu má spoustu užitečných tříd a lze také využít autentizační mechanismy Windows (potom je ale řešení závislé na doméně a nastavení oprávnění v Active Directory).

 
           [Odpovědět]

Mrkněte na ADO.NET Data Services. Umí to zpřístupnit databázi (resp. tabulky, které si řeknete), umí to třídit, stránkovat na serveru (takže je to rychlé) a můžete si pro každý objekt specifikovat oprávnění, kdo co může.

Bohužel spousta těžkých klientů se připojuje rovnou do databáze, takhle to v mnoha firmách funguje.

 
           [Odpovědět]

Díky. Problém je, že moje oprávnění se netýkají pouze dat, ale obecně toho, co kdo smí či nesmí páchat se samotnou aplikací v GUI.

 
           [Odpovědět]

To se snad ale týká databáze a ne obecného řešení rolí v aplikaci? Když budete potřebovat řešit například který uživatel může tisknout a který ne, tak vám toto bude k ničemu.

 
           [Odpovědět]

Tak tohle ADO.NET Data Services pochopitelně neřeší, ale i tahle oprávnění budou pravděpodobně uložena v databázi, takže jde jen o to nad tím napsat pár tříd.

 
           [Odpovědět]

Tedy nechci se hádat, ale nezdá se mi, že WCF Data Services (dříve pojmenované ADO.NET Data Services) by se jakkoliv hodilo k řešení tohoto problému. Z toho co jsem vyčetl na MSDN se jedná o záležitost pro webové aplikace. Pokud budou oprávnění uložena v databázi, nevím jak by se k tomu hodil tento kolos, když by stačilo pár věcí ze System.Data.SqlClient.

 
           [Odpovědět]

Řeší to problém, kdy se těžcí klienti připojují přímo do databáze a oprávnění k jednotlivým tabulkám se řeší různými uživateli v SQL, jak tazatel popisuje.
WCF Data Services databázi zpřístupní přes Web Services nebo jiné protokoly, je to de facto řešení toho aplikačního serveru, o kterém jste psal výše. Mělo by to umět autentizaci a autorizaci jen na určité objekty.

 
           [Odpovědět]

No to je ale pořád jen o přístupu do databáze což neřeší zde diskutovaný problém.

 
           [Odpovědět]

Přesně tak, problém to neřeší. Já umím udělat tabulku, kde budou uživatelé a jejich práva popsána. Umím si z toho vytahat jednotlivá oprávnění a tak, ale pořád mi přijde, že vynalézám kolo. Přece mi neříkejte, že jsem první, kdo potřebuje pár objektů a metod ve smyslu

* addUser
* addRole
* addUserInRole
* isInRole
* ...

Tohle už přece musely psát stovky lidí přede mnou, tak bych se moc divil, kdyby to už někde nebylo.

 
           [Odpovědět]

Jak už jsem zmiňoval, ve Frameworku jsou na to předpřipravené věci, ale implementovat si to musíte celé sám. Z vlastní zkušenosti mohu říct, že to vůbec není nic jednoduchého. Můžete začít třeba studiem třídy System.Security.Principal.GenericPrincipal, což bude asi základní kámen představující uživatelská oprávnění. Dále System.Security.Permissions.PrincipalPermission, což je objekt ověřující uživatelská oprávnění.

Jinak o žádném API třetích stran umožňujících nějak jednoduše řešit tuto problematiku nevím.

 
           [Odpovědět]

Připojuji klienty přímo do databáze! Říká se tomu dvouvrstvá architektura - proč se tomu proboha divíte? Správa uživatelů a rolí je sice pro mě problém, ale jako argument pro nasazení aplikačního serveru je to pro moje účely přece jen trochu overkill.

 
           [Odpovědět]

To, že se něčemu nějak říká (dvouvrstvá architektura kupříkladu), ještě neznamená, že je to vhodné a správné řešení.

Overkill to opravdu není, když už někde běží databázový server, není přece problém k němu přidat ještě jednu tenkou vrstvu, která řeší oprávnění a poskytuje data.

 
           [Odpovědět]

TO byla odpověď na p. Linharta, ale odeslali jsme to skoro najednou ;-)

Pohled na to, jak já vnímám aplikační servery je dán Javou. Napsat něco tenoučkého mezi DB a aplikaci by samozřejmě řešením bylo ;-)

 
           [Odpovědět]