16
Oct/09
0

Validation de formulaires en Erlang

Problématique

L’envoi des données de formulaire se fait par Ajax également.

Il est nécessaire de pouvoir sérialiser le formulaire afin d’envoyer les données sur le réseau, ainsi que de brancher le mécanisme côté serveur pour récupérer et valider les données.

Côté client, la sérialisation d’un formulaire se fait tout simplement en utilisant les mécanismes jQuery ; rien de spécial ici, on commencera par sérialiser un formulaire particulier avant de passer à une généralisation.

Côté serveur, nous allons mettre en oeuvre la récupération des données et leur validation. Tout ce qui vient du client doit être considéré comme non sûr et potentiellement corrompu.

La validation serveur est donc un processus absolument primordial. La pré-validation cliente est accessoire et ne sera pas traitée pour le moment.

Cette validation cliente participe à l’amélioration de l’expérience utilisateur. Pour notre part, avec l’architecture particulière mise en place où seuls les éléments mis à jour transitent entre le client et le serveur, on espère que la validation serveur ne sera pas trop pénalisante et donc suffisante dans un premier temps.

6
Oct/09
0

Mise en oeuvre de l’authentification (3 - niveau navigateur)

On met en oeuvre la partie utilisateur/interface.

Tout d’abord, on rajoute un lien dans l’en-tête du site afin de diriger sur l’url /login.html (priv/templates/views/index.haml) :

  %body
    #header
      #ids
        Guest
        %a{ 'data-event' => "login:start", :href => "/login.html" } (login)

Ce lien possède un attribut particulier data-event. Cet attribut est correct selon les normes HTML 5, et peut être utilisé sans problème dès aujourdh’ui. Pour plus d’informations, vous pouvez lire cet article de John Resig.

Cet attribut personnalisé va nous permettre de définir des liens demandant un déclenchement d’événement lors d’un click. Cet événement est la valeur de l’attribut lui même. Le comportement générique sera de ne pas déclencher le click normal (navigateur) mais de le remplacer par le déclenchement de l’événement.

28
Sep/09
0

Mise en oeuvre de l’authentification (2 - niveau serveur)

L’article précédent a défini la façon dont le code utilisateur sera stocké dans au niveau du poste client, à savoir dans un cookie dont l’altération ne sera pas possible.

Maintenant, il est nécessaire de pouvoir mettre en oeuvre cette formulation au sein de l’application. Cette dernière sera principalement privée.

22
Sep/09
0

Cookies d’authentification

Comme quasiment toute application web, il est nécessaire d’identifier l’utilisateur afin de proposer des traitements et parties de site spécifiques pour cet utilisateur (zones privées, profilage, etc.).

La tendance actuelle, concernant notamment la possibilité de mise à l’échelle ultérieure, est de stocker les éléments de fonctionnement liés à l’utilisateur (données d’état à conserver entre plusieurs requêtes) à l’intérieur de cookie.

Ce mode de fonctionnement permet de s’approcher d’une architecture de type Shared Nothing (SNA), ce qui est une des architectures les plus efficaces. Cela permet également de ne pas introduire d’entrée de jeu des mécanismes (sessions) qui sont fortement structurants et limitatifs.

Le problème de cette solution est la transition des informations complètes (et pas seulement un identifiant de session) sur le réseau et leur utilisation au niveau du poste client. Le protocol SSL étant consommateur et ne pouvant pas être utilisé sur l’ensemble d’un site, cela suppose de bloquer toute manipulation des données par un client.