IV. Interface entre le support de l'utilisateur et l'utilisateur lui-même▲
Les scripts d'interface sont constitués des fichiers inscript, connect, passperdu (et gds, mais il sera traité avec le script de connexion). Ces scripts ont besoin du support de l'utilisateur vu ci-dessus. Ils ne peuvent pas être utilisés indépendamment.
L'ensemble des scripts d'interface est fait de façon à ne générer ni cookie, ni session_start(), ni header (par exemple pour les redirections), ni die(), exit()...., bref, aucune fonction qui empécherait le script de se poursuivre (afin par exemple d'afficher un pied de page). Ceci est possible grâce au mécanisme des exceptions, appliqué ici aux « erreurs utilisateur ». Ainsi, si le mot de passe est incorrect, si l'email est faux.... ont soulèvera une exception, avec un message d'erreur, cette exception est capturée et on affiche un message d'erreur personnalisé grâce à la fonction affiche_message et éventuellement on réaffiche le formulaire, le script ayant soulevé l'exception est interrompu et on passe à la suite.
Principe
Les 3 pages fonctionnent selon le même principe. Nous définissons une fonction qui affichera le fomulaire souhaité grâce au mécanisme des templates.
S'il n'y a pas d'envoi de formulaire, nous affichons simplement celui-ci par appel de la fonction. Si le formulaire est envoyé, nous le traitons. durant le traitement nous testons diverses choses, viabilité des données, mot de passes concordants...
Suivant chaque résultat de test, il y a 3 choix.
- Le script continue simplement au test suivant en cas de succès.
- Nous levons une exception que nous capturons, puis nous affichons le message grâce à la fonction affiche_message qui prendra la place du formulaire.
- Nous levons une exception que nous capturons, puis nous rappellons la méthode d'affichage du formulaire en lui passant le message d'erreur en paramètre
IV-A. Inscription▲
- la récupération des POST avec la classe de filtrage (cf 2,3 Sécurité)
- La fonction d'affichage du formulaire
- Le traitement du formulaire si celui-ci a été envoyé.
- L'ajout dynamique de champ de formulaire
- Un chiffrage par l'algorythme RSA du mot de passe coté client, déchiffrage coté serveur
IV-A-1. Champs dynamiques▲
ch_nom: nom du champ pour le formulaire (caractères alphanumériques, sans espaces)
ch_texte : Texte affiché à coté du champ de formulaire
ch_type_affichage : R=>radio, T=>text, S=>select, A=>textarea
ch_min_size : taille minimum du texte saisi par l'utilisateur
ch_max_size : taille maximum du texte saisi par l'utilisateur
ch_obligatoire : 1: obligatoire, 0:non obligatoire
ch_ordre : Order d'affichage des champs sur le formulaire d'inscription.Pour les choix, comme les listes select ou les boutons radio, ils faut saisir les différentes valeurs à proposer dans la table champs_value
cv_id_champ : identifiant du champ saisi ci-dessus
cv_nom : le texte à afficher sur la liste select ou à coté du bouton radio
cv_ordre : ordre d'affichage.IV-A-2. Chiffrage par RSA▲
IV-B. Connexion▲
Le script de connexion utilise un GDS pour le transit et le stockage des informations. Ce GDS est créé à l'inscription et est unique à chaque membre. L'unicité êmpèche la constitution d'un dictionnaire global au site. Ce gds est utilisé à chaque connexion pour encoder le mot de p asse coté client. Ainsi, un script AJAX est chargé de chercher un GDS valable au fur et à mesure de la saisie du login sur le formulaire de connexion. Ce script distant est le fichier gds.php.
Pour empêcher les attaques par force brute, un timer est installé, et oblige un intervalle de temps entre 2 connexion. L'interval de temps est configurable dans la table config.
IV-C. Pass perdu▲
Test la validité dulogin et du mail envoyé par l'utilisateur. Si les informations sont valides, le script génére un mot de passe de 9 caractères alpha numériques et l'envoie par mail
IV-D. Conclusion partie Interface▲
