utilisateur ASP.NET parcourir les données brutes sélectionnées / restreint de sql-server

Question

Dans une application ASP.NET WebForms Je voudrais permettre à l'utilisateur final pour parcourir les données brutes sélectionnées dans une base de données sql-server.

Cependant, je voudrais restreindre l'accès à l'utilisateur de voir que quelques-unes des données basées sur le nom d'utilisateur.

Je ne sais pas comment faire cela d'une manière qui est possible pour l'utilisateur de comprendre, puisque SQL ne sait pas nécessairement à l'utilisateur.

Quelles sont les options dois-je ici?

---

En tant que base pour cela, je l'ai envisagé de créer une fonction sql par table en question. Cette fonction doit renvoyer les données que l'utilisateur est autorisé à voir, par exemple.

CREATE FUNCTION ufn_RawData_Employee(@username nvarchar(256))
RETURNS TABLE
AS ( SELECT * FROM Employee 
  WHERE [@username is allowed to view the given Employee] )

Dans une page Web l'utilisateur final peut alors entrer une instruction de type SQL comme

SELECT Name, HireDate FROM ((Employee))

où (([TableName])) pourrait alors être remplacé par ufn_RawData_[TableName]([UserName]) avant d'appeler la base de données. (Pour des raisons de sécurité ces appels pourraient alors être effectuées par un utilisateur sql dont uniquement autorisations sont des permissions SELECT à ces fonctions.)

Cependant, cette approche pourrait être trop difficile pour l'utilisateur final. Je voudrais savoir si une solution plus facile / utilisateur conviviale existe pour l'utilisateur final pour parcourir les données brutes sélectionnées?

Answer 1

Si vous ne montrez les données utilisateur d'une table, ou un point de vue (ce qui serait probablement plus utile) alors oui vous pouvez stocker le nom de ce point de vue dans une table et le récupérer avec une fonction. Vous pouvez ensuite afficher les données dans les pages, et assurez-vous que vos scripts de sélection standard ont une fonction intégrée de recherche si nécessaire.

Il n'y a pas besoin de l'utilisateur d'écrire SQL si elles ne reçoivent que des données d'une table ou une vue. Si vous devez fournir plusieurs tables / vues possibles, puis les laisser choisir un menu déroulant, mais il ne semble pas utile de leur permettre d'écrire leurs propres requêtes SQL.