J'utilise MyBatis récemment. J'ai déjà utilisé Ibatis. Dans l'ensemble, c'est similaire, mais j'ai encore rencontré de nombreux problèmes. Je vais l'enregistrer à nouveau.
Permettez-moi d'abord d'introduire la différence entre # {} et $ {} dans mybatis, comme suit:
1. # Traitez toutes les données entrantes comme une chaîne et ajoutez des devis doubles aux données automatiquement entrantes. Par exemple: commande par # user_id #, si la valeur transmise est 111, alors la valeur lorsque l'analyse en SQL est de l'ordre par "111". Si la valeur transmise est id, l'analyse en SQL est l'ordre par "id".
2. $ Affiche directement les données transmises et les génère dans SQL. Par exemple: commande par $ user_id $, si la valeur transmise est 111, alors la valeur lors de l'analyse en SQL est de l'ordre par user_id. Si la valeur transmise est id, l'analyse en SQL est l'ordre par id.
3. La méthode # peut grandement empêcher l'injection de SQL.
4. La méthode $ ne peut pas empêcher l'injection SQL.
5. La méthode $ est généralement utilisée pour passer dans des objets de base de données, tels que le passage des noms de table.
6. Généralement, si vous pouvez utiliser #, n'utilisez pas $.
Lorsque vous utilisez l'ordre par des paramètres dynamiques lors du tri MyBatis, vous devez faire attention à l'utilisation de $ au lieu de #
Remplacement des cordes
Par défaut, l'utilisation de la syntaxe de format # {} fait que MyBatis crée une propriété d'instruction prétraitée et définit une valeur de sécurité avec l'arrière-plan (tel que?). C'est sûr et rapide, et parfois vous voulez simplement insérer une chaîne qui ne change pas directement en instruction SQL. Par exemple, comme Order By, vous pouvez l'utiliser comme ceci:
Commande par $ {Columnname}
Ici, Mybatis ne modifiera ni ne s'échappera pas des chaînes.
Important: il n'est pas sûr d'accepter la sortie de contenu de l'utilisateur et de le fournir à une chaîne inchangée dans l'instruction. Cela peut conduire à des attaques d'injection SQL potentielles, vous ne devez donc pas permettre aux utilisateurs d'entrer ces champs, ou généralement de les échapper et de les vérifier vous-même.
Description de Mybatis lui-même:
Substitution de chaîne par défaut, l'utilisation de la syntaxe # {} amènera MyBatis à générer des propriétés de statement préparé et à définir les valeurs en toute sécurité par rapport aux paramètres de préparation (par exemple?). Bien que cela soit plus sûr, plus rapide et presque toujours préféré, vous voulez parfois injecter directement une chaîne non modifiée dans l'instruction SQL. Par exemple, pour l'ordre par, vous pouvez utiliser quelque chose comme ceci: Commande par $ {Columnname} Ici, MyBatis ne modifiera pas ou échappera à la chaîne. Cela conduit à des attaques d'injection SQL potentielles et donc vous devez soit interdire l'entrée des utilisateurs dans ces champs, soit toujours effectuer vos propres évasions et chèques. D'après ce qui précède, nous pouvons voir:
1. Utilisez la syntaxe du format # {} pour utiliser l'instruction de préparation dans MyBatis pour définir des valeurs en toute sécurité et exécuter SQL similaire à ce qui suit:
PréparéStatement ps = conn.preparestatement (SQL); ps.SetInt (1, id);
L'avantage est: plus sûr, plus rapide et est généralement la pratique préférée.
2. Mais parfois, vous voulez juste insérer une chaîne inchangée directement dans l'instruction SQL. Par exemple, comme Order By, vous pouvez l'utiliser comme ceci:
Commande par $ {Columnname} À l'heure actuelle, MyBatis ne modifiera ni n'échappera pas à la chaîne.
Cette méthode est similaire à:
Instruction st = conn.createStatement (); resultSet rs = St.ExecuteQuery (SQL);
Les inconvénients de cette méthode sont:
Il est dangereux d'accepter le contenu de la sortie de l'utilisateur et de fournir des chaînes inchangées dans l'instruction de cette manière, ce qui entraîne des attaques d'injection SQL potentielles, de sorte que l'utilisateur n'est pas autorisé à saisir ces champs ou à s'échapper et à vérifier par eux-mêmes.