Introduction


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 :

   · 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 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 pseudo-code ci-dessous montre comment cela fonctionne :

Code 4D : méthode base Sur authentification web
Sélectionnez

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.

Implémentation d'un dialogue de mot de passe web personnalisé


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 :

Image non disponible


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


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

code 4D : méthode base Sur authentification Web
Sélectionnez

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

code 4D : méthode base Sur connexion Web
Sélectionnez

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


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 :

code 4D : méthode WebLoginIsRequired
Sélectionnez

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 ci-dessous :

code 4D : méthode WebLoginIsOkay (sans 4DACTION)
Sélectionnez

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 :

code 4D : méthode WebLoginIsOkay (avec 4DACTION)
Sélectionnez

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

code 4D : méthode WebLoginIsOkay (simplifiée)
Sélectionnez

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 :

code 4D : méthode WebLoginSendChallenge
Sélectionnez

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


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


 
Sélectionnez

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


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 :

code 4D
Sélectionnez

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 :

Image non disponible

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

Image non disponible


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, "Case-Sensitive 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

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


Télécharger la base exemple.