Personnalisation du système des mots de passe Web

Le serveur web de 4e 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é.

À 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.

Pour comprendre le comportement de la Méthode base Sur authentification web, il est nécessaire d'expliquer comment fonctionnent 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 :

   · 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.

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 semi-dynamique 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 pseudocode 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 ? 4e 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.

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 contextuels, 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 passent 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▲

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

Personnaliser Sur connexion Web▲

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")
   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

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

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

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

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

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")

<!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é ci-dessous :</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▲

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

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 :

Les mots de passe Web ne sont pas sécurisés▲

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é :

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▲

La différentiation de casse est optionnelle▲

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.

Télécharger la base exemple.