Gathering of Tweakers

Ik wil een Data Access Component (DAC) maken die data teruggeeft op basis van een bepaalde user. De user (identity) is bepaald in ASP.NET en ik wil bepaalde views in SQLServer laten runnen in de DAC op basis van de user identity (een gebruiker mag slechts bepaalde data zien waarvoor hij geautoriseerd is).

De DAC moet gevoed worden met de identity van de user om de stored procedure calls te kunnen uitvoeren.


Hebben jullie tips om zo'n DAC op te bouwen?


Target: .NET 2.0, SQLServer2005

need more info ....

Wat bedoel je met 'slechts bepaalde data zien' ? Gaat dit over bepaalde records die hij al of niet mag zien, of gaat het over bepaalde velden die hij wel of niet mag zien, of een combinatie ?

quote:

whoami schreef op donderdag 03 juli 2008 @ 12:41:
need more info ....

Wat bedoel je met 'slechts bepaalde data zien' ? Gaat dit over bepaalde records die hij al of niet mag zien, of gaat het over bepaalde velden die hij wel of niet mag zien, of een combinatie ?

het gaat om rijen

er zijn 3 tabellen, zegge A, B en C met ieders een 1 op n relatie:

daarnaast zijn er configuratietabellen. In deze config tabellen wordt bepaald welke gebruiker welke rijen uit A B en C mag zien.

Dus als je gaat joinen, krijg je in je resultaatset te kolommen: UserId, Entiteit1, Entiteit2,Entiteit3,..., AllowedUserRole te zien?

Dan kan je toch een WHERE clausule gebruiken?

Ga je die views gewoon plat naar de gebruiker gooien of vertaal je de resultaten ook nog eens naar objecten?

quote:

gorgi_19 schreef op vrijdag 04 juli 2008 @ 10:03:
Dus als je gaat joinen, krijg je in je resultaatset te kolommen: UserId, Entiteit1, Entiteit2,Entiteit3,..., AllowedUserRole te zien?

Dan kan je toch een WHERE clausule gebruiken?

* whoami snapt ook niet wat het probleem / moeilijkheid nu precies is ?
Aangezien je het ID van de user kent, kan je toch idd gewoon filteren mbhv where ?

quote:

whoami schreef op vrijdag 04 juli 2008 @ 11:57:
[...]

* whoami snapt ook niet wat het probleem / moeilijkheid nu precies is ?
Aangezien je het ID van de user kent, kan je toch idd gewoon filteren mbhv where ?

ik zat me af te vragen hoe de public API er uit zou kunnen zien voor zo'n DAC.


stel: MyDataDAC class

public static MyCustomList GetMyCustomList(param1, param 2, etc.....)
{
}


Ik zit nog te stoeien met de API. Ik denk dat de public methods geen elementen van de user moet hebben, dit zou ik graag willen zien in de constructor. De user ID kan ik dan opslaan als member op de DAC. Elke method kan dan de user ID raadplegen voor de filtering. Het nadeel hier van is dat de DAC zelf niet meer static kan zijn. Wil ik dat wel dan vervuil ik elke method met user ID zaken.

ps: ik weet nu nog niet hoe ik de user ID kan opbouwen, weet nog te weinig van de environment (bij een AD kan ik de Windows Identity gebruiken, maar zo niet dan een custom identity), vandaar even mijn vraagteken over het juiste type van UserID.

Je hebt het over stored procedures. Ik zou eerst wel eens willen zien hoe jij de userid gaat checken in die stored procs, nl. via de credentials op de active connection of middels gewone parameters. Want indien het 1e, dan kun je middels connections gewoon security regelen, en indien 2 dan is het gewoon een where clause.

Ook is het anno 2008 IMHO gewoon tijdverknoeien om je nog bezig te houden met het schrijven van een DAL, die zijn er genoeg.