L'autorisation EXECUTE est refusée sur les types de table définis par l'utilisateur?


87

J'ai une question sur les types de table définis par l' utilisateur dans SQL Server 2008.

Pour le besoin de l'une des applications ASP.NET, nous avons défini nos propres types de table sur SQL Server 2008 pour les utiliser comme paramètres dans les procédures stockées (lors de l'exécution de la commande sql dans l'application ASP.NET, nous transmettons l'objet DataTable en tant que paramètre de la procédure stockée voir ici pour un exemple )

Le problème est que lorsque nous exécutons la commande Sql (exécutons la procédure stockée) à partir d'ASP.NET, nous obtenons une erreur:

L'autorisation EXECUTE a été refusée sur l'objet 'ourTableType', base de données 'ourDatabase', schéma 'ourSchema'.

Pourquoi est-ce si? Pourquoi avons-nous besoin de définir l'autorisation sur les types de table définis par l'utilisateur? Pourquoi ne suffit-il pas d'avoir une autorisation définie uniquement sur la procédure stockée qui l'utilise? Et si nous devons le régler , peu importe quoi, pourquoi il n'y a pas de EXECUTEtype d'autorisation à mettre en fenêtre des propriétés que ce soit (je ne vois que Control, References, Take Ownership, View Definition)?

Ce que je ne comprends pas non plus, c'est que la définition de l'autorisation Controldans la fenêtre des propriétés résout le problème et la procédure stockée s'exécute sans problèmes.



Merci! J'ai cherché mais clairement pas assez bon: /
Janez

Essayez de mettre AS dboà la fin. Comme ceci: GRANT EXEC ON TYPE::[schema].[typename] TO [User] AS dbo. A travaillé pour moi.
Jonathan

Un doublon possible du paramètre de valeur
LCJ

Réponses:


197

J'espère vraiment que vous avez résolu ce problème maintenant, étant donné que la question a presque 4 mois, mais au cas où vous ne l'auriez pas fait, voici ce que je pense être la réponse.

GRANT EXEC ON TYPE::[schema].[typename] TO [User]
GO

9
Mes 2 cents: En fonction de votre mécanisme d'authentification de connexion, vous devrez peut-être accorder exec au groupe public. Donc, votre bourse ressemblerait à ceci: GRANT EXEC ON TYPE :: [schema]. [Typename] TO [Public] GO
Sudhanshu Mishra

@dotnetguy merci beaucoup, aucune des solutions n'a fonctionné pour moi sauf la vôtre.
Mazen el Senih

3

Si votre procédure stockée utilise SQL dynamique, ce qui signifie que le @sqlest généré puis exécuté via exec @sql, vous aurez besoin d'une autorisation accordée sur les tables sous-jacentes.

Une solution consiste à modifier la procédure stockée pour qu'elle s'exécute en tant qu'utilisateur différent . Si vous le faites fonctionner en tant que SELF, il sera exécuté sous le créateur du processus stocké, ce qui est extrêmement dangereux. Pourtant, si vous n'avez pas d'autre option:

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS SELF

1
Merci de l'avoir signalé. Mais la procédure stockée ne contient aucun SQL dynamique. Uniquement les INSERT INTOinstructions de table générales et "UPDATE" pour lesquelles cet utilisateur a toutes les autorisations dont il a besoin. De plus, cet utilisateur / login est spécialement réservé / créé pour que cette application ASP.NET puisse se connecter à cette base de données et exécuter uniquement des procédures stockées (pas de création, etc., le créateur est toujours 'sa').
Janez

Merci, c'était le problème pour moi. Les autres lecteurs confrontés à ce problème peuvent consulter les autorisations SQL Server sur les processus stockés avec SQL dynamique pour plus de conseils.
Nickolay
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.