none
[C# 5/.NET4] Validation de TextBox RRS feed

  • Question

  • Bonjour,

    je suis lis actuellement cet ouvrage :

    http://www.editions-eni.fr/livres/c-5-developpez-des-applications-windows-avec-visual-studio-2013/.ca09590490c4bebf6503fdd965e12be1.html

    (et je me régale).

    Dans un des chapitres, il parle des contrôles utilisateurs et de la gestion des erreurs via errorProvider.

    Créer un contrôle dérivant de textBox appelé EmailTextBox permet donc de centraliser sa validation des e-mails une seule fois via errorProvider. Jusque là, je suis OK.

    - Est ce qu'implémenter IEMailValidator ne serait pas une meilleure implémentation ?

    Si ce champ doit être inséré dans une base de données, j'ai peur de l'injection SQL et donc tous les contrôles doivent être filtrés. So :

    - Est ce qu'il y a du code ou une option disponible existante afin de ne pas ré-inventer la roue ?

    - Est ce que l'on doit créer une interface INoSqlValidator permettant ainsi d'avoir un contrôle de type E-mail sans code SQL ?

    Merci,

    Vincent

    mercredi 14 janvier 2015 17:23

Réponses

  • J'ai trouvé cet article qui en parle pour ASP.NET :

    http://msdn.microsoft.com/en-us/library/ff648339.aspx

    Parallèlement sous .NET 4, Entity Framework avec les chaînes SQL paramétrées, cela rendrait impossible l'injection SQL.

    A suivre...

    jeudi 15 janvier 2015 21:48
  • Bonjour,

    Les errorProvider & co ne sont là que pour avertir l'utilisateur que l'email n'est pas correct. C'est juste une information de l'UI.

    La validation des données doit se faire autre par que dans le code de l'UI.

    Même si cette approche peut paraître redondante, c'est beaucoup plus "secure".

    Votre projet devrait/peut avoir la structure suivante :

    Projet UI

    --- Projet Services

    --- Projet Données

    Votre écran UI demande a un service de sauvegarder un objet. Le service valide les données et envoie celles ci au projet Données qui enregistre dans la base de données.

    Le errorProvider fait partie du Projet UI, il n'est là que pour la cosmétique. A la limite, vous pouvez ne pas en mettre. Quand on fait l'enregistrement, c'est le projet Service qui avertit l'UI que c'est pas cool ce qu'il lui envoie.

    concernant l'injection SQL, à partir du moment ou vous utilisez des Parameters, vous n'avez plus de problème.

    var sql = "Select Nom From Persons Where LastName = @LastName";
    ...
    command.AddParameterWithValue("@LastName", lastName);
    ...


    Richard Clark
    Consultant - Formateur .NET
    http://www.c2i.fr
    Depuis 1996: le 1er site .NET francophone

    vendredi 16 janvier 2015 08:48

Toutes les réponses

  • Bonjour, Vincent,

    C'est une question intéressante qui exige plus d'expérience peut-être, mais je vais rechercher au moins pour vous donner une idée. Je vais partager l'information trouvée.

    Cordialement,

    Nina


    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.


    jeudi 15 janvier 2015 16:48
    Modérateur
  • J'ai trouvé cet article qui en parle pour ASP.NET :

    http://msdn.microsoft.com/en-us/library/ff648339.aspx

    Parallèlement sous .NET 4, Entity Framework avec les chaînes SQL paramétrées, cela rendrait impossible l'injection SQL.

    A suivre...

    jeudi 15 janvier 2015 21:48
  • Bonjour,

    Les errorProvider & co ne sont là que pour avertir l'utilisateur que l'email n'est pas correct. C'est juste une information de l'UI.

    La validation des données doit se faire autre par que dans le code de l'UI.

    Même si cette approche peut paraître redondante, c'est beaucoup plus "secure".

    Votre projet devrait/peut avoir la structure suivante :

    Projet UI

    --- Projet Services

    --- Projet Données

    Votre écran UI demande a un service de sauvegarder un objet. Le service valide les données et envoie celles ci au projet Données qui enregistre dans la base de données.

    Le errorProvider fait partie du Projet UI, il n'est là que pour la cosmétique. A la limite, vous pouvez ne pas en mettre. Quand on fait l'enregistrement, c'est le projet Service qui avertit l'UI que c'est pas cool ce qu'il lui envoie.

    concernant l'injection SQL, à partir du moment ou vous utilisez des Parameters, vous n'avez plus de problème.

    var sql = "Select Nom From Persons Where LastName = @LastName";
    ...
    command.AddParameterWithValue("@LastName", lastName);
    ...


    Richard Clark
    Consultant - Formateur .NET
    http://www.c2i.fr
    Depuis 1996: le 1er site .NET francophone

    vendredi 16 janvier 2015 08:48
  • C'est un peu violent comme architecture quand même non ?

    Je pense que je vais devoir réviser mes patterns.

    vendredi 16 janvier 2015 19:57