J'ai une procédure stockée qui fait beaucoup de suppression. Des centaines de milliers de disques. Il ne va pas être dirigé de la demande, mais je suis toujours concerné, que l'un de mes clients le gère accidentellement (j'ai eu des problèmes plus tôt en raison de leur "curiosité"): D
Oui. Il y a des sauvegardes et des trucs comme ça, mais je pensais ... ne pas les faire peur ... Y a-t-il un moyen de demander à l'utilisateur "es-tu sûr?" Avant de l'exécuter? :) merci
8 Réponses :
Je suppose que vous pourriez avoir un paramètre appelé "Confirmation" qui nécessite une chaîne spécifique (E, G, "Je sais ce que je fais") à transmettre, s'il n'est pas défini, ou n'est pas mal défini, juste retour de la procédure sans exécuter le code principal. Pas exactement ce que vous vouliez, mais c'est une option.
par exemple - (syntaxe non testée et probablement terrible)
Cela pourrait fonctionner, mais je pense que cela deviendra rapidement une "copie & coller et ignorer le paramètre"
D'accord, mais il n'y a rien à empêcher de contourner quoi que ce soit s'ils ont accès à la SproC directement. Bien préférable d'ajouter un accès approprié / exécuter la sécurité autour du tout.
En bref, non.
La théorie va que quiconque a des autorisations pour trouver et pouvoir exécuter une procédure stockée, devrait être autorisée. Il serait préférable de limiter les autorisations de sorte que celles ayant une curiosité excédentaire ne disposent pas des autorisations pour exécuter cela.
L'autre option, moins sécurisée, il serait nécessaire d'exiger un secret prédéfini qui doit être transmis comme un paramètre - bien sûr, ils pourraient simplement scruter la procédure stockée pour trouver le secret si ...
Bien sûr, l'autre point serait: si ce n'est pas appelable, pourquoi l'inclure? Après tout, lorsque vous venez faire des tâches de type administrateur, vous pouvez avoir les instructions scriptées en tant que fichier que vous pouvez conserver sur votre propre machine
Vous pouvez utiliser une entrée de bit appelée @userknowswhattheyaredoing et vérifier si elle est vraie avant d'exécuter. Si c'est faux, imprimez un message amical et revenez gracieusement de la procédure
Vous pouvez ajouter un paramètre @reallyrealyryrealdelete à la SPROC qui servira de mesure de sécurité: s'il est défini sur Yesyesyes commettre la transaction.
La procédure peut nécessiter une dispute avec une valeur spécifique, comme 'oui, je sais ce que je fais' . Ou il peut rechercher une ligne une table spéciale avec une confirmation similaire et un horodatage récent.
Utilisez une approche flagonnée à plusieurs niveaux:
1) Control Exécutez la sécurité, comme: p> 2) Utilisez un nom de procédure vraiment descriptif / effrayant, comme 3) Placez un grand commentaire accrocheur au début de la procédure stockée p> 4) rendre l'utilisateur passe Dans un code d'accès spécial obscurci: p> CREATE PROCEDURE Will_Delete_All_Your_Data
(
@SpecialCode varchar(30)
)
IF @SpecialCode!=CHAR(83)+CHAR(112)+CHAR(101)+CHAR(99)+CHAR(105)+CHAR(97)+CHAR(108)+CHAR(67)+CHAR(111)+CHAR(100)+CHAR(101)
BEGIN
RETURN 999
END
...
Avez-vous besoin de les supprimer vraiment de la DB? Si je peux me permettre un espace supplémentaire, je vais mettre un drapeau "supprimé" dans mes tables et une dernière colonne mise à jour. De cette façon, si un enregistrement est supprimé accidentellement au moins, je peux généralement le suivre et la restaurer assez facilement. Juste une pensée.
Voici encore une autre approche, qui, à mon avis, est apte à ce que le cas particulier lorsqu'une procédure soit appelée par un utilisateur directement plutôt que d'une application.
Je dois dire, il propose moins de problèmes pour l'utilisateur en tant que plus. (Peut-être, de manière disproportionnée) pour le développeur par rapport à la plupart des autres suggestions. Vous décidez si cela vous convient. P>
Quoi qu'il en soit, voici. P>
Tout d'abord, vous créez une table spéciale, essentiellement, l'idée est qu'un SP critique devrait être appelé deux fois: il enregistre son appel et informe l'utilisateur de répéter le appelez dans un certain temps de temps comme une confirmation de leur intention, et avec le deuxième appel, s'il est fait en conséquence, il procède en réalisation de sa tâche. p> de sorte que la partie de départ de chaque procédure critique aurait donc Logic: P> CriticalCalls code> pour enregistrer les appels vers des procédures critiques. La table aurait une structure comme celle-ci: p> EXECUTE @result = CheckCriticalCalls 'ThisProcedureName';
IF @result = -1 BEGIN
PRINT 'Call me again';
RETURN;
END;
... /* go on with the task */
Pourquoi ne configurez-vous pas les autorisations pour vos processus stockés? De cette façon, seuls les utilisateurs autorisés peuvent l'exécuter.
@Le gentleman Elite: Je ne dis pas que les utilisateurs autorisés peuvent parfois souhaiter se sentir comme des êtres humains plutôt que des machines. Cette affaire particulière montre plutôt que certains développeurs ne menaient pas à percevoir les utilisateurs comme de simples mortels. :)