Utiliser IF EXISTS avec une procédure stockée comme argument

Vous pouvez transformer votre procédure en fonction:

 create function dbo.authenticate(@UserName varchar(50), @Password varchar(50)) returns @found table(userName varchar(50), userPass varchar(50)) as begin -- some of your internal table declare @user table (userName varchar(50), userPass varchar(50)); insert into @user values ('John', '123'), ('Jack', '345'); insert into @found (userName, userPass) select u.userName, u.userPass from @user u where u.userName = @UserName and u.userPass = @Password ; return; end; go if exists(select * from dbo.authenticate('John', '123')) begin print 'exists'; end; 

EXISTS prend une sous-requête SELECT pas les résultats d'une procédure stockée. Voir MSDN . Vous devrez répliquer votre SELECT partir de votre instruction EXISTS ou remplir une table avec les résultats avant les EXISTS . par exemple

 INSERT INTO #authenticate (col1, col2, col3) EXEC authenticate @UserName, @Password IF EXISTS (SELECT 1 FROM #authenticate) BEGIN SELECT * from Users; END 

Je vois plusieurs problèmes de design:

1

La méthode " Authentifier " renvoie un set de lignes. Pourquoi? Il s'appelle "authentifier" – pas "SelectAuthenticatedUserInfo". Je suppose que cette procédure fait plus d'un travail.

Le split en méthode d' authentification réelle qui donne probablement une variable de sortie avec l'identificateur de session ou l'indicateur de bit oui / non = ok / fault. Et créez une autre procédure quelque chose comme dbo.SelectAuthUserProfile qui est appelée une fois au démarrage de l'application, appelle à partir de dbo.Authenticate et si elle réussit – returnne un set de lignes avec des données d'accord.

2

Ce choix ressemble à un travail régulier, je veux dire – il ne s'agit probablement pas d'un travail ponctuel de «bas niveau» au démarrage ou à la connection / déconnection d'une application. Pourquoi effectuez-vous la méthode d' authentification ? Êtes-vous sérieux que vous voulez passer le nom d'user et (!) Mot de passe chaque fois que vous voulez sélectionner des données? L'authentification est un travail ponctuel par session (ou même des scénarios plus longs).

Authentifiez votre user, puis vérifiez s'il est déjà authentifié ou non. Stockez vos données de session quelque part, passez seulement une key ou quelque chose (ou même ne passez rien – il y a quelques trucs avec ## ou # tables, spid + time de connection et ainsi de suite).

3

Il ne me semble pas que chaque user puisse voir le contenu de la table des Users . L'access peut être contrôlé par les outils internes du server sql.

Créez un schéma pour les process stockés spécifiques à l'administrateur, créez un rôle pour ces super-users, accordez les procédures de ce schéma. Cela exclura toute possibilité pour un user régulier d'exécuter un tel proc.

4

Pensez davantage à la gestion de l'access aux différentes parties de votre système. A la question "Cet user est-il autorisé à effectuer une telle action?" vous essayez de répondre "Il est authentifié!" D'accord, authentifié. Et alors? A-t-il une permission ou non?

Authentifier l'user une fois, puis – contrôler ses permissions. Il ne peut pas y avoir de méthode "d'authentification" à l'intérieur d'un proc régulier. Mais "IsPermitted" je suppose est censé être. (cet article est en corrélation avec la première – à de nombreuses responsabilités pour un proc)

5

En outre, pensez à ceci: autorisé à voir ces ordres, mais pas autorisés à les voir. Pouvez-vous l'organiser avec un appel proc comme if exec then ?