dimanche 18 novembre 2012

NDateTime (DateTime du .NET porté pour JavaScript)

Voilà ma dernière création, une librairie JavaScript qui regroupe les fonctionnalités de base d'un objet DateTime en .NET

Plus besoin de se battre avec les dates JavaScript! :)

Pour tous les développeurs web.
Si vous avez des idées (Ajouts/Commentaires) n'hésitez pas!



http://ndatetime.codeplex.com

dimanche 19 février 2012

Comment ouvrir une nouvelle fenêtre en javascript à la suite d'un postback (ASP.NET)

Il peut paraître assez simple à première vue d'ouvrir une fenêtre en javascript à la suite d'un postback. On aurait tendance à ce dire qu'il suffit d'enregistrer un script avec la commande window.open. Le problème c'est que les navigateurs sont maintenant munis de "Pop-up blocker". Les navigateurs empêchent donc toutes ouvertures de fenêtre en javascript sauf si l'action provient d'un clic sur un lien ou un bouton.

Heureusement, il y a une façon de contourner ce problème. La solution est d'ouvrir la fenêtre sur l'évènement onclick côté client et de lui assigner un nom unique. Ensuite, lorsque vous atteignez l'évènement buttonclick côté serveur, il suffit d'utiliser la commande window.open avec le même nom spécifié côté client. Le navigateur va donc utiliser la même fenêtre ouverte précédemment côté client. De cette façon, on respecte les règles d'ouvertures de fenêtre en javascript des navigateurs.

Voici un exemple très simple, je vous l'accorde, mais qui démontre la solution : Voici le bouton du bouton dans notre fichier aspx
<asp:Button ID="ButtonOpenGoogle" Text="Cliquer pour ouvrir Google" /> OnClick="ButtonOpenGoogle_Click" /> OnClientClick="window.open('about:blank', 'windowPopupGoogle');" />
Voici le code de l'évènement click du bouton côté serveur
Dans l'exemple ci-dessus la fenêtre est identifiée de façon unique avec le nom 'windowPopupGoogle'.

Il peut arriver aussi qu'une fois côté serveur, on veule annuler l'ouverture de la fenêtre, il suffit donc de récupérer le handler de la fenêtre et d'effectuer une window.close telle que dans l'exemple ci-dessous.
 protected void ButtonOpenGoogle_Click(object sender, EventArgs e)
{
ScriptManager.RegisterStartupScript(this, typeof(Page), "windowPopupGoogleScript", "var win = window.open('about:blank','windowPopupGoogle');win.close();", true);
}
Voilà!

mardi 24 janvier 2012

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! ;)