Comment neutraliser un spambot qui utilise un formulaire web

Un spambot est un logiciel qui permet d'envoyer des pourriels. Il existe plusieurs types de spambots. Certains recherchent des adresses courriel en parcourant des pages web pour ainsi se créer une liste d'adresses et ensuite d'envoyer des pourriels à cette liste. Il en existe également pour les forums, les wikis donc pour les formulaires web en général.

Solution Captcha

Il existe une technologie qui se nomme Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart) qui permet d'effectuer une vérification en utilisant la capacité d'analyse d'image ou de son de l'être humain. Les Captcha visuels fournissent des mécanismes d'altération de l'image (déformation légère, points aléatoires, ligne transversale, etc.) afin que les logiciels de reconnaissance optique de caractères ne puissent pas décoder les caractères sur l'image. Malheureusement, les spambots les plus perfectionnés sont en mesure de contourner les Captcha. Certains Captcha sont tellement déformés pour éviter une reconnaissance automatique que même les internautes ne peuvent les reconnaître.

Exemple de Captcha

Solution Honeypot (Pot de miel)

Il existe une façon que je trouve assez intéressante pour régler ce problème. Il s'agit en gros de tendre un piège aux spambots afin de pouvoir les neutraliser. Les spambots ne sont pas capables de distinguer à quoi servent les champs de votre formulaire. Ils sont capables de détecter les types de champs, mais non leurs fonctions. Les spambots ont l'habitude de remplir de données bidon tous les champs du formulaire web (afin de contourner les RequiredValidator) alors grosso modo le truc est d'ajouter un champ bidon (caché en CSS) afin que l'intru y ajoute des données. Ce champ n'étant pas visible aux utilisateurs "normaux", nous pourrons donc déduire que le formulaire a été saisi par un robot si le champ contient des données et par un utilisateur si le champ est vide.

Dans le l'événement OnInit de la page de formulaire, nous allons ajouter le champ texte bidon et lui assigner une classe CSS afin de pouvoir le cacher. La classe CSS aura un nom généré au hasard au format suivant :

trap + nombre aléatoire de 1 à 1000

Le nom de la classe est généré afin que le spambot ne puisse pas détecter l'astuce.

protected override void OnInit(EventArgs e)

        {

            
base.OnInit(e);
            //Add a HoneyPot to block spambots
            //Generate a random class name
            Random random = new Random();

            String honeyPotCssClassName = String.Concat("trap", random.Next(1000).ToString());

            TextBox textHoneyPot = new TextBox()

            {
                
ID = "textHoneyPot",

                CssClass = honeyPotCssClassName
            };

            Form.Controls.Add(textHoneyPot);



            ClientScript.RegisterClientScriptBlock(typeof(Page), "_dynamiccsstrap", String.Concat("<style type=\"text/css\">.",honeyPotCssClassName," { display:none !important; } </style>"), false);
  
        }

Lors que le formulaire est retourné au serveur, on doit s'assurer que le champ textHoneyPot est vide avant de poursuivre le traitement.

 protected void ButtonSend_Click(object sender, EventArgs e)

        {

            
TextBox textHoneyPot = (TextBox)Form.FindControl("textHoneyPot");

            if (Page.IsValid && String.IsNullOrEmpty(textHoneyPot.Text))

            {

//Do stuff
}
}

Voilà, le problème des spambots devrait être réglé, du moins jusqu'à la prochaine percée! ;)

Opérateur conditionnel (?:) et opérateur de nulle coalescence (??) en C#

L'opérateur conditionnel et l’opérateur de nulle coalescence peuvent s'avérer très utiles pour simplifier votre code et le rendre également plus lisible.

L’opérateur conditionnel

L'opérateur conditionnel (également appelé opérateur ternaire) permet de d'évaluer une condition et ensuite d'évaluer l'une ou l'autre des parties pour en retourner le résultat. La syntaxe est z ? x : y
Donc dans l'exemple ci-dessous, si la condition est (a==1) est vraie, x sera égal à 1 sinon il sera égal à 0.

int x = (a==1) ? 1 : 0;

Le premier opérande de l'opérateur conditionnel (a==1) doit être une expression d'un type qui peut être converti implicitement en bool ou une expression d'un type qui implémente operator true.
Le type de l’expression conditionnel est déterminé par le deuxième et troisième opérande. En se base sur le modèle suivant :

• Si y et z sont du même type, il s'agit alors du type de l'expression conditionnelle.
• Sinon, s'il existe une conversion implicite de X en Y, mais pas de Y en X, Y est alors le type de l'expression conditionnelle.
• Sinon, s'il existe une conversion implicite de Y en X, mais pas de X en Y, X est alors le type de l'expression conditionnelle.
• Sinon, le type d'expression ne peut pas être déterminé et une erreur de compilation se produit.

Voir documentation sur MSDN http://msdn.microsoft.com/fr-fr/library/aa691313(v=vs.71).aspx

Donc au lieu d’écrire une expression tel que :

string GetValueName(int value)

{

if (value == 1)

return "Value 1";
else

return "Value 2";
}

On peu tout simplement écrire :

string GetValueName(int value)


{

return (value == 1) ? "Value 1" : "Value 2";
}

L’opérateur de nulle coalescence

Tout d'abord, le mot coalescence signifie grossièrement « Unir 2 parties en une seule, fusionner ». L’opérateur de nulle coalescence vérifie si le premier opérande est non null, si c’est le cas cette valeur est retournée, sinon c’est la valeur du deuxième opérande qui est retourné. La syntaxe est x ?? y
Donc dans l'exemple ci-dessous, si la condition est la variable age n’égale pas à null, la fonction GetAge retournera la valeur de age, sinon elle retournera 0.

int GetAge(Nullable age)


{

return age ?? 0;
}

Vous remarquerez également que la conversion age (Nullable) en int lors du retour de la fonction s’est faite par l’opérateur de nulle coalescence, donc pas besoin de cast.

Utiliser LINQ to SQL sur une base de données SQL Server Compact Edition (SQL CE)

Il est simple d’utiliser LINQ to SQL afin de se connecter à une base de données SQL Server. Il suffit de faire glisser les tables ou procédures stockées de la fenêtre Server Explorer vers votre fichier DBML. Toutefois lorsque la base de données est de format SQL Server Compact Edition, vous risquez d’avoir un message d’erreur « The selected object(s) use an unsupported data provider. »



Il existe un utilitaire en ligne de commande qui se nomme SqlMetal et qui permet d’outre passer ce problème. Cet outil permet de générer un fichier dbml à partir d’importe quelle base de données (vous devrez vous procurer le provider LINQ to pour les bases de données autres que Microsoft SQL Server). SqlMetal.exe se trouve habituellement dans

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin

Voici un exemple concret d’utilisation. Nous avons une application avec une base de données HumanResources.sdf qui contient une table Employee. Pour générer notre fichier DBML il suffit d’ouvrir une console de ligne de commande (cmd) et de se positionner dans le dossier de notre projet. Ensuite exécuter la commande

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\SqlMetal.exe" /conn:"Data Source=HumanResources.sdf" /dbml:DataClassesHumanResources.dbml /provider:SQLCompact

Vous pouvez maintenant retourner dans Visual Studio et inclure le fichier dbml généré à votre projet.


Pour plus d'information sur SqlMetal : http://msdn.microsoft.com/fr-fr/library/bb386987.aspx

Vous êtes maintenant prêt à utiliser LINQ to SQL sur votre SQL Server Compact Edition!

Notes

Il est également possible d'automatiser cette procédure pour ne pas avoir à refaire ces étapes lorsque que vous modifiez votre base de données. Une façon de faire est d’appeler SqlMetal dans l’évènement Pre-build de votre projet.



La commande de Pre-build pour notre exemple serait :

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\SqlMetal.exe" /conn:"Data Source=$(ProjectDir)\HumanResources.sdf" /dbml:$(ProjectDir)\DataClassesHumanResources.dbml /provider:SQLCompact

En espérant que cet article vous ait été utile.

Comment mocker un DataContext et une Table LINQ to SQL avec Moles

Avez-vous déjà essayés de mocker un DataContext ou une table LINQ to SQL? Cette tâche est ardue à réaliser avec des plateformes de mocking classiques, car le DataContext n’hérite d’aucune interface et la classe Table est sealed. Heureusement, Moles apporte une solution toute simple. Moles est un framework qui permet de détourner n’importe quelle méthode .NET, incluant même les méthodes virtuelles/statiques dans des classes sealed.

Allons-y d’un exemple! Nous avons ici une application WinForms classique contenant un fichier DataClassesEmployee.dbml. Ce fichier contient une table Employee. C’est cette table que l’on va mocker.



Nous avons également une opération EmployeeGetOperation qui se charge de trouver un employé dans la base de données en fonction de son Id.

    public class EmployeeGetOperation
    {
        
private Int32 _id = -1;
        public Int32 Id
        {
            
get { return _id; }
            set { _id = value; }
}

        private Employee _result = null;
        public Employee Result
        {
            
get { return _result; }
            set { _result = value; }
}

        DataClassesEmployeeDataContext _context = new DataClassesEmployeeDataContext();
        public DataClassesEmployeeDataContext Context
        {
            
get { return _context; }
            set { _context = value; }
}

        public EmployeeGetOperation(Int32 Id)
        {
            
this.Id = Id;
}

        public EmployeeGetOperation(Int32 Id, DataClassesEmployeeDataContext Context) 
            : this(Id)
        {
            
this.Context = Context;
}

        public void Execute()
        {
            
Result = Context.Employees.FirstOrDefault(e => e.ID == Id);
}
}

Nous allons maintenant ajouter un projet de test à notre solution afin de pouvoir créer notre test unitaire. N'oubliez pas d'ajouter la référence System.Data.Linq et celle du projet qui contient votre fichier dbml (MockingLINQtoSQLApp) à votre projet de test. La prochaine étape est de générer un fichier moles pour les 2 références ci-dessus. Pour ce faire vous cliquer droit sur la référence dans votre projet de test et ensuite cliquer sur "Add Moles Assembly". Répéter l'opération pour System.Data.Linq.



Nous voilà rendus au test unitaire. La première étape sera d'instancier un MDataClassesEmployeeDataContext via les nouveaux types générés par Moles, ensuite nous créerons une table d'employé à partir d'une liste fictive et finalement nous détournerons notre propriété Employees de notre nouveau DataContext vers notre table fictive.

Voici maintenant le code de notre test unitaire EmployeeGetOperationTests.

    [TestClass]
    public class EmployeeGetOperationTests
    {
        
[TestMethod]
        [HostType("Moles")]
        public void EmployeeGetOperationTests_GetValidUser_ReturnValidUser()
        {
            
//Mock du DataContext
            var context = new MDataClassesEmployeeDataContext();

            //Liste d'employé fictive à utiliser pour le test
            var employees = new List<Employee>()
            {
                
new Employee() { ID = 1, FirstName = "Bud", LastName = "Spencer"},
                new Employee() { ID = 2, FirstName = "Terence", LastName = "Hill"}
};

            //Créer une table à partir de notre liste fictive
            MTable<Employee> employeeMockTable = SetupLinqTable(employees);

            //Détourner la propriété Employees de notre context vers notre table fictive
            context.EmployeesGet = () => employeeMockTable;

            //Appeler notre opération de sélection d'un employé via notre context mocké
            EmployeeGetOperation operation = new EmployeeGetOperation(1, context);
            operation.Execute();
            //Vérifier que l'employé retourné est bien celui que nous attendions
            Assert.AreEqual<Int32>(1, operation.Result.ID);
            Assert.AreEqual<String>("Bud", operation.Result.FirstName);
            Assert.AreEqual<String>("Spencer", operation.Result.LastName);
}

        //Fonction qui retourne une Table à partir d'un IEnumerable
        private MTable<T> SetupLinqTable<T>(IEnumerable<T> linqList) where T : class
        {
            
MTable<T> tempTable = new MTable<T>();
            tempTable.Bind(linqList.AsQueryable());
            return tempTable;
}
}

Il est maintenant temps de rouler le test.



Voilà! Nous avons créé un test unitaire en mockant la couche d'accès aux données (LINQ to SQL) grâce à Moles!

Utilisation du mot-clé yield pour palier aux variables de retour temporaire

Il vous est surement arrivé de devoir retourner un IEnumerable dans une de vos méthodes. La façon classique, est de se déclarer une variable temporaire afin de pouvoir ajouter le contenu désiré et ensuite retourner la collection.

Voici un exemple qui affiche les nombres pairs entre dans un intervalle donné:

   public IEnumerable<int> GetPairNumber(int From, int To)
        {
            
List<int> retVal = new List<int>();
            
for (int indexNumber = From; indexNumber < To; indexNumber++)
            {
if (indexNumber % 2 == 0)
                {
                    
retVal.Add(indexNumber);
}
}
return retVal;
}

Il est toute fois possible d'éviter la déclaration et l'utilisation de la variable retVal. Pour ce faire, on peut utiliser les mots-clés yield return dans un bloc itérateur.
Le mot-clé yield indique au compilateur que la méthode dans laquelle il apparait est un bloc itérateur. Le compilateur génère une classe pour implémenter le comportement exprimé dans le bloc itérateur. Dans le bloc itérateur, le mot clé yield est utilisé avec le mot clé return pour fournir une valeur à l'objet énumérateur. C'est donc cette valeur qui est retournée.


L'exemple ci-dessous reprend effectue exactement la même opération, mais en évitant la variable retVal.

   public IEnumerable<int> GetPairNumber(int From, int To)
        {
            
for (int indexNumber = From; indexNumber < To; indexNumber++)
            {
                
if (indexNumber % 2 == 0)
                {
                    
yield return indexNumber;
}
}
}

Ok ça ne changera pas le monde, mais c’est un petit truc intéressant à savoir :)

Contrôler l'arrêt d'un service Windows perso (.NET)

Lorsqu'on développe un service Windows, il est essentiel de contrôler le moment où le service s'arrêtera surtout lorsqu'il s'agit d'un traitement en lot. Vous ne voudriez probablement pas que votre service s'arrête en plein traitement, car un utilisateur à lancer la commande net stop votre_service.

Prenons par exemple un service qui roule en continu et qui vérifie toutes les 15 secondes les enregistrements qui ont été ajoutés à une base de données afin de pouvoir les traiter. Dans cet exemple, le service ne doit pas s'arrêter tant qu'il n'a pas fini de traiter les nouveaux enregistrements.

Seul le code servant au contrôle du service sera présenté dans cette publication

Voici le code du service ServiceData (ServiceData.cs)

public partial class ServiceData : ServiceBase
{
Thread dataProcessingThread = null;

        public ServiceData()
        {
            
InitializeComponent();
}

        protected override void OnStart(string[] args)
        {
            
dataProcessingThread = new Thread(DataProcessing.ProcessPendingData);
            dataProcessingThread.Start();
}

        protected override void OnStop()
        {
            
DataProcessing.ResetEvent.Set();
            while (dataProcessingThread.IsAlive)
            {
                
this.RequestAdditionalTime(5000);
                Thread.Sleep(5000);
}
            
}
}

Lors du démarrage du service, nous lançons, dans l'évènement OnStart, un thread qui va s'exécuter tout au long du service. Nous verrons la classe DataProcessing un peu plus loin... Regardons tout d'abord l'arrêt du service. Dans la fonction OnStop la commande

DataProcessing.ResetEvent.Set();

sert à déclencher l'évènement d'arrêt du service. La boucle while sert ensuite à attendre que les enregistrements restant à traiter se terminent. La commande suivante

this.RequestAdditionalTime(5000);

sert à avertir le Service Control Manager (SCM) que le service requiert 5 secondes de plus pour s'arrêter. Si nous omettons cette commande, le SCM croira que le service ne répond plus. Cette boucle vérifie en fait à tout les 5 secondes si le travail du thread est terminé.


Voici le code de la classe DataProcessing (DataProcessing.cs)

public static class DataProcessing
    {
        
private static ManualResetEvent resetEvent = new ManualResetEvent(false);
        public static ManualResetEvent ResetEvent
        {
            
get { return resetEvent; }
            set { resetEvent = value; }
}

        public static void ProcessPendingData()
        { 
            
do
            {
                
//All stuff here will not be interrupted until they finish
}
            while (!ResetEvent.WaitOne(15000));
        
}
    
}

Le code suivant

private static ManualResetEvent resetEvent = new ManualResetEvent(false);
        public static ManualResetEvent ResetEvent
        {
            
get { return resetEvent; }
            set { resetEvent = value; }
}

définit le ResetEvent qui sert à avertir le thread qu'un événement est survenu.

public static void ProcessPendingData()
        { 
            
do
            {
                
//All stuff here will not be interrupted until they finish
}
            while (!ResetEvent.WaitOne(15000));
        
}

La méthode statique ProcessPendingData sert à traiter les enregistrements. Tout ce qui se trouve à l'intérieur du do-while ne sera pas interrompu par un arrêt de service.
Donc la boucle va s'exécuter toutes les 15 secondes tant et aussi longtemps qu'une demande d'arrêt n'a pas été formulée. Votre lot d'enregistrements pourra donc être traité sans être interrompu!