version 11.2
La Méthode base Sur authentification SQL permet de filtrer les requêtes adressées au serveur SQL intégré de 4D. Le filtrage peut être effectué sur la base du nom, du mot de passe ainsi que (facultativement) de l'adresse IP de l'utilisateur. Le développeur peut utiliser sa propre table d'utilisateurs ou celle des utilisateurs 4D pour évaluer les identifiants de connexion. Une fois la connexion validée, l'emploi de la commande CHANGER UTILISATEUR COURANT permet de contrôler les accès de la requête au sein de la base 4D.
Lorsqu'elle existe, la Méthode base Sur authentification SQL est automatiquement appelée par 4D ou 4D Server à chaque connexion externe au serveur SQL. Le système interne de gestion des utilisateurs de 4D n'est alors pas activé. La connexion est acceptée si la méthode base retourne Vrai dans $0 et est rejetée sinon.
Note : L'instruction ODBC LOGIN(SQL_INTERNAL;$utilisateur;$motdepasse) ne déclenche pas l'appel de la Méthode base Sur authentification SQL car il s'agit dans ce cas d'une connexion interne.
La méthode base reçoit jusqu'à trois paramètres de type Texte, passés par 4D ($1, $2 et $3), et retourne un booléen, $0. Voici la description de ces paramètres :
| Paramètres | Type | Description |
| $1 | Texte | Nom d'utilisateur |
| $2 | Texte | Mot de passe |
| $3 | Texte | (Facultatif) Adresse IP du client à l'origine de la requête |
| $0 | Booléen | Vrai = requête acceptée, Faux = requête rejetée |
Vous devez déclarer ces paramètres de la manière suivante :
` Méthode base Sur authentification Web C_TEXTE($1;$2;$3) C_BOOLEEN($0) ... ` Code pour la méthode
Le mot de passe ($2) est reçu en texte standard.
Vous devez contrôler les identifiants de la connexion SQL dans la Méthode base Sur authentification SQL. Par exemple, vous pouvez contrôler le nom et le mot de passe à l'aide d'une table d'utilisateurs personnalisée. Si les identifiants sont valides, passez Vrai dans $0 pour accepter la connexion et donc la requête. 4D ouvre alors une session SQL pour l'utilisateur.
Sinon, passez Faux dans $0, dans ce cas la connexion est rejetée.
Par défaut, $0 vaut Faux. Si la Méthode base Sur authentification SQL existe et si $0 n'est pas défini, toutes les connexions sont donc rejetées.
Note : Si la Méthode base Sur authentification SQL n'existe pas, la connexion est évaluée à l'aide du système intégré de gestion des utilisateurs de 4D (s'il est actif, c'est-à-dire si un mot de passe a été attribué au Super_Utilisateur).
Une fois connexion acceptée, vous pouvez appeler la commande CHANGER UTILISATEUR COURANT dans la Méthode base Sur authentification SQL. L'utilisation de cette commande est conseillée car elle permet un niveau de sécurité plus élevé. Ce principe d'authentification virtuelle a le double avantage de permettre le contrôle des actions de la connexion et de masquer pour l'extérieur les identifiants de la connexion dans la session SQL 4D.
Lorsque le système intégré de mots de passe 4D n'est pas activé, l'exécution de la commande CHANGER UTILISATEUR COURANT est sans effet, les utilisateurs sont connectés avec les droits du Super_Utilisateur (accès libre).
Cet exemple de Méthode base Sur authentification SQL vérifie que la demande de connexion provient du réseau interne, valide les identifiants puis affecte les droits d'utilisateur "sql_user" pour la session SQL.
C_TEXTE($1;$2;$3)
C_BOOLEEN ($0)
`$1 : utilisateur
`$2 : mot de passe
`{$3 : Adresse IP du client}
APPELER SUR ERREUR ("SQL_error")
Si (checkInternalIP($3))
`La méthode checkInternalIP vérifie que l'adresse IP est interne
Si ($1="victor") & ($2="hugo")
CHANGER UTILISATEUR COURANT("sql_user";"")
Si (OK=1)
$0:=Vrai
Sinon
$0:=Faux
Fin de si
Sinon
$0:=Faux
Fin de si
Sinon
$0:=Faux
Fin de si
Référence