> Tech > Protection des instructions SPL

Protection des instructions SPL

Tech - Par iTPro - Publié le 24 juin 2010
email

Les techniques de traitement d'erreurs décrites dans le corps de l'article permettent de protéger toute instruction SQL en l'encadrant par une paire d'instructions comme celles illustrées en H et J sur la figure 1. Cette technique d'encadrement convient pour

Protection des instructions SPL

des instructions Select et autres instructions de manipulation de données
individuelles, mais est trop encombrante pour qu’on l’associe à 
chaque Set, Case, et autre instruction de programmation SPL (Stored
Procedure Language). Bien que les exceptions dans ces instructions de
programmation soient moins probables que dans des instructions de
manipulation de données, elles peuvent néanmoins se produire. Avec le
gestionnaire des exceptions présent en D, figure 1, les exceptions présentes
dans des instructions encadrées sont ignorées et le flux d’exécution
se poursuit.

            Pour
protéger toutes les instructions dans une procédure SQL, on peut étendre
la technique de traitement d’erreurs comme dans la figure A, qui montre
les segments modifiés de la procédure catalogué GetRank de la figure 1.
Cette technique étendue implique de régler la variable ExceptionState
sur ExceptionStateNotChecking avant tout groupe d’une ou plusieurs
instructions dans lequel SQLState n’est pas testé individuellement (B
et D, figure A). Après chaque section de code de ce type, on ajoute une
instruction Leave Main conditionnelle pour quitter la procédure si une
exception se produit pour une instruction quelconque du groupe (en C et E)
(observez comment il s’en suit que la dernière de ces instructions
conditionnelles est l’avant-dernière de la procédure, juste avant de
positionner l’état d’achèvement “ OK ”, comme illustré
en E.) Le seul autre changement nécessaire se trouve dans le gestionnaire
d’exceptions, où il faut donner au paramètre SQLStateOut la valeur
SQLState pour une exception se produisant dans une section du code non
testé (en A) (cela suppose de toujours quitter la procédure quand une
exception survient dans une section non testée du code.)

            Notons
que cette technique ne quitte la procédure qu’à  la fin d’une section
de code non testée, et que la valeur SQLState renvoyée concerne la dernière
exception (il se peut que de multiples instructions dans la section
causent une exception). Sans être parfaite, cette solution permet de
surveiller les exceptions sans trop compliquer le code. On peut utiliser
cette méthode exhaustive selon sa propre “ recette ”, en
combinant les deux morceaux supplémentaires du code avec les deux
morceaux de code correspondants qui encadrent les instructions testées,
comme je l’ai fait dans la figure A juste avant et après
l’instruction Select. Pour simplifier l’utilisation de cette
technique, je garde ces deux tranches de code dans un fichier source et
les place, par copier-coller, de part et d’autre de chaque instruction
testée. –
PC

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010