Personnalisation du système des mots de passe Web

Personnalisation du système des mots de passe Web
Par David ADAMS
Note technique 4D-200609-25-FR
Version 1 - Date 1 septembre 2006
Résumé
Le serveur Web de 4D fournit un support automatique pour les mots de passe HTTP à travers la Méthode
base Sur authentification Web. Mais cette fonctionnalité ne permet pas d'ajouter une page d'erreur à afficher
si le dialogue des mots de passe est annulé. Heureusement, cette limitation est aisément contournée en
ajoutant un peu de code dans la Méthode base Sur connexion Web ou dans n'importe quelle méthode appelée
par 4DACTION.
4D Notes techniques
Copyright © 1985-2009 4D SAS - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte.
L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs
utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D
SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la licence
électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés
ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par
photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que
l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques
enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple
Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial
Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires
respectifs.
1 / 13
Personnalisation du système des mots de passe Web
Résumé
Le serveur web de 4ème Dimension fournit un support pour les mots de passe HTTP au travers de la
Méthode base Sur authentification web. Une fois activée et configurée, cette fonctionnalité envoie
automatiquement une vérification pour une méthode ou une ressource de la base. Mais il y a une limitation à
ce système. Si la fenêtre des mots de passe est annulée, une page blanche est affichée dans le navigateur. Cet
écran blanc prête à confusion et donne l'impression à l'utilisateur final qu'il n'est plus connecté.
A la place d'un écran blanc, il serait préférable de montrer une page avec un texte informatif, une aide, des
liens vers les autres pages du site, ou toute autre information intéressante. Contourner le comportement par
défaut de la Méthode base Sur authentification web n'est pas difficile, mais cela nécessite d'utiliser une
stratégie différente. Au lieu de l'utilisation du système automatique, l'authentification est assurée par
quelques lignes de code dans la Méthode base Sur connexion web et quelques méthodes appelées au moyen
de 4DACTION.
Cette note technique explique pourquoi le système Sur authentification web fonctionne de cette façon, et
décrit le système de mot de passe web qui peut la remplacer. Incluses dans cette note, se trouvent deux bases
de données : "Web_LoginStandard", qui illustre le fonctionnement du système Sur authentification web
fonctionne, et "Web_LoginCustom", qui implémente la solution personnalisée.
A propos des mots de passe web
Pour comprendre le comportement de la Méthode base Sur authentification web, il est nécessaire
d'expliquer comment fonctionne les mots de passe HTTP. Tout d'abord, examinons le fonctionnement
typique quand le dialogue des mots de passe est annulé. Pour l'utilisateur, voici ce qu'il semble se passer :
1. Une page est demandée dans le navigateur.
2. Le serveur demande un nom d'utilisateur et un mot de passe dans un dialogue.
3. Si le dialogue des mots de passe est annulé, le serveur renvoie une page d'erreur.
En interne, ces étapes sont différentes :
1. Une page est demandée dans le navigateur.
2. Le serveur envoie un code HTTP 401 et une page d'erreur.
3. Le navigateur comprend le code 401 comme une indication qu'un nom d'utilisateur et un mot de
passe sont requis.
4. Le navigateur présente un dialogue pour récupérer le nom d'utilisateur et le mot de passe. Le
navigateur n'affiche pas de page d'erreur à ce stade.
5. Si l'utilisateur annule le dialogue des mots de passe, le navigateur affiche la page d'erreur envoyée
par le serveur dans le point 2.
Si les différences entre le fonctionnement apparent et le fonctionnement réel sont peu claires, voici quelques
explications qui les rendront plus explicites :
2 / 13
• Le dialogue des mots de passe est affiché et contrôlé par le navigateur, pas par le serveur. Donc les
différents navigateurs dessinent des dialogues à l'aspect différent.
• Si le dialogue des mots de passe affiché par le navigateur est annulé, il n'y a pas de message envoyé par
le serveur web. Ainsi la page d'erreur doit déjà être présente dans le navigateur.
En gardant ces différents points à l'esprit, voyons comment 4D fonctionne.
Le fonctionnement standard de 4D
La méthode base Sur authentification Web est comprise dans chaque base 4D comme étant l'emplacement
du code d'authentification web. La méthode se lance toutes les fois qu'une URL ou qu'un rappel semidynamique appelle une méthode 4D. Sur authentification Web reçoit six paramètres de type texte avec
différentes informations concernant la requête web. Pour accepter une requête, passez Vrai dans $0. Pour
envoyer un mot de passe au navigateur, passez Faux dans $0. Le pseudo-code ci-dessous montre comment
cela fonctionne :
C_BOOLEEN($0;$acceptConnection_b)
C_TEXTE($1) ` ;$url_t)
C_TEXTE ($2) `;$httpHeader_t)
C_TEXTE ($3) `;$clientIPAddress_t)
C_TEXTE ($4) `;$serverIPAddress_t)
C_TEXTE ($5;$userName_t)
C_TEXTE ($6;$password_t)
$userName_t:=$5
$password_t:=$6
Si(WebLoginIsOkay ($userName_t;$password_t)
$acceptConnection_b:=Vrai
Sinon
$acceptConnection_:=Faux
Fin de si
$0:=$acceptConnection_b
Que se passe-t-il quand $0 est passé à Faux ? 4ème Dimension termine le processus de la requête et renvoie
une réponse HTTP avec le statut "401 Unauthorized". De plus, cela inclut la partie "WWW-authenticate"
requise pour une réponse HTTP complète avec mot de passe.
La réponse HTTP ci-dessous montre exactement ce que l'en-tête inclut :
HTTP/1.1 401 Authorization Required.
Server: 4D_WebStar_D/2004
Date: Tue, 10 Oct 2006 00:21:20 GMT
WWW-Authenticate: Basic realm="Web_Login_Default.4DB"
Une réponse avec un statut "401" peut inclure une page pour afficher une information si le dialogue des mots
de passe est annulé, mais la réponse générée par le Sur authentification Web ne permet pas cela. Ainsi,
quand un dialogue de mot de passe est annulé, il n'y a rien à afficher. Il n'existe pas de moyen pour ajouter
manuellement une page d'erreur avec une réponse envoyée par Sur authentification Web. Pour contourner
cette limitation nous acceptons toutes les requêtes dans le Sur authentification Web puis traitons
manuellement dans le Sur connexion Web et/ou dans les méthodes appelées par 4DACTION.
3 / 13
Implémentation d'un dialogue de mot de passe web personnalisé
Résumé
L'implémentation d'un dialogue de mots de passe personnalisé dans 4D est simple. Il y a seulement deux
tâches importantes à mettre en place :
1. tester les mots de passe lorsque c'est nécessaire
2. Envoyer une réponse complète et personnalisée (HTTP 401) lorsque c'est nécessaire.
En fonction de l'utilisation de la base sur le web, il y a différentes façons d'approcher ces problématiques. La
stratégie implémentée dans la base exemple et traitée dans cette note technique supporte la protection par
mot de passe pour tous les accès non-contextuels, incluant les requêtes pour les pages individuelles, les
appels 4DCGI et les appels 4DACTION.
Contrôle des flux du Web Server 4D
De façon interne, le contrôle des flux dans le serveur Web 4D varie beaucoup en fonction des systèmes
d'appels non-contextuel, comme illustré dans le diagramme ci-dessous :
Notez que les trois types de requêtes provoquent un passage par la Méthode base Sur authentification Web
et que les appels par 4DACTION ne passe pas par la Méthode base Sur connexion Web. Donc, le lieu le
plus évident pour mettre votre code d'authentification est la Méthode base Sur authentification Web.
Sinon, ce sont les limitations de la Méthode base Sur authentification Web qui nous pousse à construire
une solution personnalisée en premier lieu. Si tous les appels sont canalisés par le Sur connexion Web, alors
l'authentification peut être faite ici. Sinon, si quelques méthodes sont appelées par des 4DACTION, elles
doivent être authentifiées individuellement. Heureusement, aucune de ces étapes n'est complexe et toutes
sont implémentées dans la base exemple "Web_LoginCustom". Regardons le code nécessaire dans chaque
cas.
Personnaliser Sur authentification Web
4 / 13
Dans la solution personnalisée de mot de passe, Sur authentification Web nécessite un peu de code pour
accepter la requête et stocker les noms et mots de passe de l'utilisateur pour des utilisations ultérieures,
comme montré ci-dessous (le code dans la base exemple est un peu plus dense) :
C_BOOLEEN($0;$acceptConnection_b)
C_TEXTE($1;$2;$3;$4;$5;$6)
`On stocke le nom et mot de passe de l'utilisateur dans des variables process pour les méthodes
`utilisées par 4DACTION
C_TEXTE(WebDemo_UserName_t)
C_TEXTE(WebDemo_UserPassword_t)
WebDemo_UserName_t:=$5
WebDemo_UserPassword_t:=$6
$0:=Vrai
En retournant Vrai, comme montré ci-dessus, on évite le comportement automatique des mots de passe de
4D. De plus, cela permet de faire passer toutes les requêtes web. Il est important de tester toutes les requêtes
manuellement. Il y a seulement deux endroits où des tests doivent être faits, ainsi que mentionné : dans Sur
connexion Web et dans chaque méthode appelée directement par un 4DACTION. Pour les sites qui utilisent
des 4DCGI au lieu de 4DACTION, tous les tests de sécurité peuvent être faits dans Sur connexion Web.
Astuce :
4DACTION offre peu d'avantages par rapport à 4DCGI. En fait, il apporte de nombreux désavantages, par
exemple, dans la version actuelle de 4D, les noms des méthodes sont vues sur le web. Mis à part les
considérations de sécurité, un corollaire de ce comportement est que le changement du nom de la méthode
dans 4D casse tous les liens externes.
Personnaliser Sur connexion Web
La Méthode base Sur connexion Web se lance à chaque fois qu'une mauvaise URL ou qu'un appel 4DCGI
est soumis. Ci-dessous voici le code utilisé dans la base "Web_LoginCustom" :
C_TEXTE($1;$url_t)
C_TEXTE($2)`;$httpHeader_t)
C_TEXTE($3)`;$clientIPAddress_t)
C_TEXTE ($4)`;$serverIPAddress_t)
C_TEXTE ($5;$userName_t)
C_TEXTE ($6;$password_t)
$url_t:=$1
$userName_t:=$5
$password_t:=$6
Si (WebLoginIsRequired ($url_t))
$loginOkay_b:=WebLoginIsOkay ($userName_t;$password_t)
Si (Non($loginOkay_b))
WebLoginSendChallenge
Fin de si
Fin de si
Si($loginOkay_b)
Au cas ou
: ($url_t="/protected.html")
5 / 13
ENVOYER FICHIER HTML ("protected/page_reached.html")
: ($url_t="/4DCGI/CallMethodWith4DCGI@")
MethodCalledBy4DCGI
Sinon
C_TEXTE(WebDemo_RequestedURL_t)
WebDemo_RequestedURL_t:=$1` la valeur est lue semi-dynamiquement par la page 404
ENVOYER FICHIER HTML("not_found.html")
Fin de cas
Fin de si
Tout le travail est effectué par trois méthodes : WebLoginIsRequired, WebLoginIsOkay et
WebLoginSendChallenge. Aucune de ces méthodes n'est longue et compliquée.
La méthode WebLoginIsRequired
Les sites Web incluent typiquement un mélange d'informations protégées et publiques. La méthode
WebLoginIsRequired fournit un lien central du code pour tester si une URL spécifique requiert une
authentification. En interne, cette méthode utilise quelques conventions pour identifier les ressources
protégées, comme le montre le code ci-dessous :
C_BOOLEEN($0;$loginRequired_b)
C_TEXTE($1;$url_t)
$url_t:=$1
$loginRequired_b:=Faux
Au cas ou
: ($url_t="/protected@")
`Utilisation d'un mot de passe pour tout ce qui est caché dans le répertoire protégé : "Protected"
$loginRequired_b:=Vrai
: ($url_t="/4DCGI@") `
`Utilisation d'un mot de passe pour tous les appels par 4DCGI
$loginRequired_b:=Vrai
: ($url_t="/4DACTION@")
`Utilisation d'un mot de passe pour tous les appels par 4DACTION
$loginRequired_b:=Vrai
Sinon
$loginRequired_b:=Faux
Fin de cas
$0:=$loginRequired_b
Le code de la base "Web_LoginCustom", comme montré ci-dessus, est en fait un peu plus dense que ce
simple squelette. Dans une base spécifique, la logique peut être étendue, affinée et ré-écrite si nécessaire.
La méthode WebLoginIsOkay
La méthode WebLoginIsOkay dans la base exemple est simplement une ossature. Elle ne fait que tester si le
nom d'utilisateur et le mot de passe fournis par le navigateur correspondent aux valeurs "hard-codées" dans
la méthode elle-même. En dépit de sa simplicité, cette méthode est correctement localisée dans la chaîne
d'appel pour gérer toute tâche d'authentification. La forme la plus simple de la méthode est montrée cidessous :
6 / 13
C_BOOLEEN($0;$loginIsOkay_b)
C_TEXTE($1;$userName_t)
C_TEXTE($2;$password_t)
$loginIsOkay_b:=Faux
Si (($userName_t="guest") & ($password_t="4D"))
$loginIsOkay_b:=Vrai
Fin de si
$0:=$loginIsOkay_b
Dans une base en production, la logique de cette méthode peut être étendue, si nécessaire. Par exemple, les
valeurs devant être saisies, comme le nom et le mot de passe, peuvent être stockées dans des enregistrements
ou dans des documents externes.
La version de la méthode montrée ci-dessus est adéquate si 4DACTION n'est pas utilisé. Sinon, si
4DACTION est utilisé, le nom de l'utilisateur et le mot de passe doivent être stockés dans Sur
authentification Web pour vérification. Il y a différentes façons de programmer dans ce contexte.
L'approche utilisée dans la base exemple est de stocker le nom de l'utilisateur et son mot de passe dans Sur
authentification web, comme montré plus haut, puis de tester ces valeurs dans la méthode
WebLoginIsOkay si aucun paramètre n'est transmis. La version développée de la méthode listée ci-dessous
est utilisée dans la base exemple :
C_BOOLEEN($0;$loginIsOkay_b)
C_TEXTE($1;$userName_t)
C_TEXTE($2;$password_t)
$loginIsOkay_b:=Faux
Si(Nombre de parametres=2)
$userName_t:=$1
$password_t:=$2
Sinon
` Le nom de l'utilisateur et le mot de passe sont sauvegardés dans Sur authentification Web
Si (Indefinie(WebDemo_UserName_t))` Cela ne devrait pas se produire
WebDemo_UserName_t:=""
Fin de si
Si (Indefinie(WebDemo_UserPassword_t))` Cela ne devrait pas se produire
WebDemo_UserPassword_t:=""
Fin de si
$userName_t:=WebDemo_UserName_t
$password_t:=WebDemo_UserPassword_t
Fin de si
Si (($userName_t="guest") &( $password_t="4D"))
$loginIsOkay_b:=Vrai
Fin de si
$0:=$loginIsOkay_b
Cette version de la méthode peut maintenant gérer les requêtes d'authentification à partir de la Méthode base
Sur connexion web ou n'importe quelle méthode appelée par 4DACTION. Comme le nom de l'utilisateur et
7 / 13
son mot de passe ont déjà été stockés par la Méthode base Sur authentification web, certains développeurs
peuvent souhaiter simplifier la méthode comme ci-dessous :
C_BOOLEEN($0;$loginIsOkay_b)
C_TEXTE($1;$userName_t)
C_TEXTE($2;$password_t)
$loginIsOkay_b:=Faux
` Le nom de l'utilisateur et son mot de passe sont stockés dans la
`la Méthode base Sur authentification Web
Si (Indefinie(WebDemo_UserName_t))` Ceci ne devrait pas se produire
WebDemo_UserName_t:=""
Fin de si
Si (Indefinie(WebDemo_UserPassword_t))` Ceci ne devrait pas se produire
WebDemo_UserPassword_t:=""
Fin de si
Si ((WebDemo_UserName_t="guest") & (WebDemo_UserPassword_t="4D"))
$loginIsOkay_b:=Vrai
Fin de si
$0:=$loginIsOkay_b
La méthode WebLoginSendChallenge
Le code de la méthode WebLoginSendChallenge peut sembler un peu complexe mais, en fin de compte, il
met simplement en place les valeurs nécessaires dans l'en-tête HTTP pour provoquer une demande de mot de
passe et ajouter le texte d'une page d'erreur. Le code complet de la méthode est présenté ci-dessous :
TABLEAU TEXTE(WebDemo_HttpHeaderNames_at;3)
TABLEAU TEXTE(WebDemo_HttpHeaderValues_at;3)
WebDemo_HttpHeaderNames_at{1}:="X-Version" ` Ce doit être le premier élément du tableau.
WebDemo_HttpHeaderValues_at{1}:="1.1"
WebDemo_HttpHeaderNames_at{2}:="X-STATUS" ` Ce doit être le second élément du tableau.
WebDemo_HttpHeaderValues_at{2}:="401" ` "Not Authorized". Ceci indique au navigateur de
`demander un mot de passe.
C_TEXTE($realm_text)
`Cette information est obligatoire pour gérer un mot de passe
` mais vous pouvez changer le nom du domaine pour gérer votre système
$realm_text:="" ` Par exemple : Basic realm="Web Login Demo"
$realm_text:=$realm_text+"Basic realm="
$realm_text:=$realm_text+Caractere(Guillemets )
$realm_text:=$realm_text+"Web Login Demo"
$realm_text:=$realm_text+Caractere(Guillemets )
WebDemo_HttpHeaderNames_at{3}:="WWW-Authenticate"
WebDemo_HttpHeaderValues_at{3}:=$realm_text
FIXER ENTETE HTTP(WebDemo_HttpHeaderNames_at;WebDemo_HttpHeaderValues_at)
ENVOYER FICHIER HTML("password_challenge.html")
8 / 13
Le code HTTP/HTML ci-dessous vous montre le code produit. L'essentiel du document, commençant par
<!DOCTYPE HTML, est le contenu du document "password_challenge.html". Les parties de l'en-tête modifiées
par le code ont été passés en gras pour être mises en valeur :
HTTP/1.1 401 Authorization Required.
Server: 4D_WebStar_D/2004
Date: Tue, 10 Oct 2006 02:28:11 GMT
WWW-Authenticate: Basic realm="Web Login Demo"
Connection: close
Last-Modified: Tue, 10 Oct 2006 02:28:11 GMT
Expires: Wed, 11 Oct 2006 02:28:11 GMT
Content-Type: text/html;Charset=ISO-8859-1
Content-Length: 1092
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Mot de passe obligatoire</title>
<link
rel="Stylesheet"
type="text/css"
title="Styles for 4D Web Log-in Examples"
href="/styles.css"
rev="Stylesheet">
</head>
<body>
<h1>Nom d'utilisateur et mot de passe requis.</h1>
<p>Un nom d'utilisateur et un mot de passe sont obligatoires pour accéder à la page ou à la méthode souhaitée. Saisissez un
Utilisateur et un Mot de passe valides dans le dialogue présenté par le navigateur. Un Exemple de dialogue vous est présenté cidessous :</p>
<img
src="password_help.jpg"
alt="Password dialog"
width="527"
height="385">
<p><b>A noter </b>: L'utilisateur est <span class="html_text">"guest"</span> et le mot de passe est <span
class="html_text">"4D"</span>. Souvenez-vous qu'une fois que l'utilisateur et le mot de passe ont été acceptés, le navigateur
continue de les envoyer avec chaque nouvelle requête. Toutes les requêtes suivantes seront donc acceptées, jusqu'à ce que l'on
quitte le navigateur.</p>
<p><a href="/index.html">Accueil</a></p>
</body>
</html>
Authentification avec 4DACTION
Les routines dans la base exemple sont construites pour traiter l'authentification avec la Méthode base Sur
connexion Web ou avec une méthode projet. Ainsi que montré dans le diagramme précédent, les appels
avec 4DACTION passent par Sur authentification Web puis vers les méthodes spécifiques. Dans la base
avec gestion personnalisée, le nom d'utilisateur et le mot de passe sont stockés dans des variables process
connues par la méthode WebLoginIsOkay ; cette approche simplifie l'authentification dans des méthodes
spécifiques, comme illustré dans l'exemple ci-dessous :
9 / 13
C_TEXTE($0;$1)`Obligatoires pour les méthodes appelées par 4DACTION.
Si (WebLoginIsOkay =Faux)
WebLoginSendChallenge
Sinon` La connexion est OK
ENVOYER FICHIER HTML ("protected/method_ran_through_4daction.html")
Fin de si
Sur authentification Web contre solution personnalisée
La sortie de l'en-tête HTTP montrée ci-dessus est fonctionnellement identifique aux en-têtes produits par les
"challenges". Les sections significatives des deux versions sont montrées étape par étape ci-dessous pour
comparaison :
HTTP/1.1 401 Authorization Required.
Server: 4D_WebStar_D/2004
WWW-Authenticate: Basicrealm="Web_Login_Default.4DB"
HTTP/1.1 401 Authorization Required.
Server: 4D_WebStar_D/2004
WWW-Authenticate: Basic realm="Web Login Demo"
La seule différence entre les deux est le nom du domaine (realm). Dans la version personnalisée, le nom du
domaine est librement configurable. Dans la version Sur authentification Web, le nom du domaine est
automatiquement construit à partir du nom de la structure de la base de données. La plus grande différence
entre les deux est dans la suite. Dans le cas du Sur authentification Web, rien ne suit. Avec la version
personnalisée, une pleine page d'information suit. Alors, si le dialogue du mot de passe est annulé dans le
navigateur, la page incluse avec le challenge est montrée. Ci-dessous, illustration de la page d'erreur produite
par la base exemple :
10 / 13
Notes additionnelles sur les mots de passe Web
Les mots de passe Web ne sont pas sécurisés
Le point suivant ne doit pas être oublié : les mots de passe Web ne sont pas sécurisés. Ce n'est pas un bug :
c'est ainsi que le système HTTP a été conçu à l'origine. Quand un utilisateur et son mot de passe sont
transmis, ils sont combinés ensemble et convertis en base64. Par exemple, le nom d'utilisateur "guest" avec
le mot de passe "4D" sont transmis de cette façon :
Authorization: Basic Z3Vlc3Q6NEQ=
La chaîne Z3Vlc3Q6NEQ= est une version en base64 de la chaîne guest:4D. Il n'y a pas d'encryptage
fournit par l'authentification HTTP Basic à aucun moment. De plus, une fois que le mot de passe a été
accepté, toutes les pages ou autres documents envoyés à travers le réseau ne sont pas sécurisés. Si un site
nécessite un cryptage, utilisez SSL (HTTPS).
N'utilisez pas les mots de passe 4D à travers le Web
Le système de mot de passe du serveur Web de 4D inclut différentes options dans le dialogue Web des
Préférences :
Préférences -> Web -> Avancé :
11 / 13
Si l'option "Utiliser mots de passe" est cochée, l'option "Inclure les mots de passe 4D" est alors activée. Si
vous cochez aussi cette option, le système des mots de passe de 4D pourra comparer les noms d'utilisateurs
Web et leur mot de passe avec les utilisateurs et mots de passe 4D. Donnez un mot de passe par le web n'est
pas sécurisé, et en donnant cette possibilité, on rend les mots de passe 4D non- sécurisés. Cette situation est
particulièrement dangereuse dans un environnement combiné 4D Client/Serveur Web. Donner les noms
d'utilisateurs et mot de passe à travers le web expose les références qui alors sont utilisées pour se connecter
avec 4D Client.
Note : l'option "Utiliser mots de passe" est requise par la solution personnalisée décrite dans cette note
technique.
Le navigateur se souvient des mots de passe Web
Le web est un protocole sans état, c'est-à-dire qu'aucune information n'est retenue entre les requêtes. Ainsi, si
un site Web demande un mot de passe, celui-ci doit être envoyé avec chaque requête. Ill est normal, pour un
site, de saisir un nom d'utilisateur et un mot de passe une fois et de naviguer ensuite librement. Pour
simplifier l'utilisation, le navigateur crée l'illusion que le mot de passe est requis une seule fois. En interne, le
navigateur se souvient du nom d'utilisateur et du mot de passe et continue de les envoyer avec chaque
nouvelle requête, tant que le navigateur reste ouvert. Si vous testez les mots de passe Web, gardez ce point à
l'esprit.
Quelquefois, il est nécessaire de quitter le navigateur et de le relancer pour continuer à tester. Une autre
stratégie de développement est de lancer plusieurs navigateurs pour éviter d'avoir à quitter un navigateur
plusieurs fois.
Astuce : une extension Firefox indispensable pour développeur Web, est disponible à l'adresse suivante :
http://chrispederick.com/work/webdeveloper/
Elle permet d'effacer les mot de passe HTTP à la volée.
Regardez dans "Miscellaneous -> Clear Private Data -> Clear HTTP authentication option.
La différentiation de casse est optionnelle
Il appartient à chaque site Web de décider si le nom d'utilisateur et mot de passe doivent différencier la casse
(majuscule ou minuscule) ou pas. Avec 4D, il est parfois maladroit de comparer les chaînes avec
différentiation de casse. Pour plus de détails sur ce point, consultez la note technique US 05-41, "CaseSensitive Operations in 4th Dimension." La base exemple inclus une variété de méthodes prêtes à l'emploi,
incluant une routine comparant une chaîne avec différentiation de casse appelée CS_AlphasAreEqual.
Conclusion
12 / 13
Le serveur Web de 4D fournit un support automatique pour les mots de passe HTTP à travers la Méthode
base Sur authentification Web. Mais cette fonctionnalité ne permet pas d'ajouter une page d'erreur à
afficher si le dialogue des mots de passe est annulé. Heureusement, cette limitation est aisément contournée
en ajoutant un peu de code dans la Méthode base Sur connexion Web ou dans n'importe quelle méthode
appelée par 4DACTION.
13 / 13