Configuration du serveur SQL de 4D

Le serveur SQL de 4D autorise les accès externes aux données stockées dans la base 4D. Pour les applications tierces et les applications 4D, ces accès s’effectuent via un pilote ODBC 4D. Il est également possible d'effectuer des connexions directes entre une application cliente 4D et 4D Server. Toutes les connexions sont effectuées via le protocole TCP/IP.

Le serveur SQL d’une application 4D peut être stoppé ou démarré à tout moment. En outre, pour des raisons de performances et de sécurité, vous pouvez définir le port TCP et l’adresse IP d’écoute et restreindre les possibilités d’accès à la base de données 4D.

L’accès externe au serveur SQL de 4D peut être effectué soit via ODBC (toutes configurations), soit directement (application cliente 4D connectée à 4D Server). Ce principe est résumé dans le schéma suivant :

En bleu : connexions via ODBC
En rouge : connexions directes

Au niveau des requêtes, l'ouverture d'une connexion externe directe ou via ODBC s'effectue à l'aide de la commande SQL LOGIN. Pour plus d'informations, reportez-vous à la description de cette commande.

• Connexions via ODBC : 4D fournit un pilote ODBC (ou driver ODBC) permettant à toute application tierce (tableur de type Excel®, autre SGBD...) ou à une autre application 4D de se connecter au serveur SQL de 4D. Le pilote ODBC 4D doit être installé sur le poste de la partie SQL cliente. L’installation et la configuration du pilote ODBC 4D sont détaillées dans un manuel séparé.
• Connexions directes : Seule une application 4D Server peut répondre aux requêtes SQL directes provenant d’autres applications 4D. De même, seules les applications 4D de la gamme "Professional" peuvent ouvrir une connexion directe vers une autre application 4D. Durant une connexion directe, l’échange de données s’effectue automatiquement en mode synchrone, ce qui élimine les questions liées à la synchronisation et à l’intégrité des données. Une seule connexion est autorisée par process. Si vous souhaitez établir plusieurs connexions simultanément, vous devez créer autant de process que nécessaire. Les connexions directes peuvent être sécurisées via la sélection de l’option Activer TLS du côté cible de la connexion (4D Server) dans la page "SQL" des Propriétés de la base. Les connexions directes ne sont autorisées par 4D Server que si le serveur SQL est démarré. Les connexions directes ont pour principal avantage d’accélérer les échanges.

Le serveur SQL de 4D peut être démarré et stoppé de trois manières :

• Manuellement, via la commande Démarrer le serveur SQL dans le menu Exécution de 4D :
  

  Note : Avec 4D Server, cette commande est accessible sous forme de bouton dans la Page Serveur SQL.

  Lorsque le serveur est lancé, le libellé de cette commande devient Arrêter le serveur SQL.

• Automatiquement au démarrage de l’application, via les Propriétés de la base. Pour cela, affichez la page SQL et cochez l’option Lancer le serveur SQL au démarrage :
  

• Par programmation, via les commandes LANCER SERVEUR SQL et ARRETER SERVEUR SQL (thème “SQL”).
  Lorsque le serveur SQL est arrêté (ou tant qu’il n’a pas été lancé), 4D ne répond à aucune requête SQL externe.

Note : L’arrêt du serveur SQL n’a pas d’influence sur le fonctionnement du moteur SQL de 4D. Le moteur SQL est accessible en permanence pour les requêtes internes.

Il est possible de configurer les paramètres de publication par défaut du serveur SQL intégré de 4D. Ces paramètres sont accessibles dans la page SQL des Propriétés de la base. 

• L’option Lancer le serveur SQL au démarrage permet de démarrer le serveur SQL au démarrage de l’application.

• Port TCP : Par défaut, le serveur SQL de 4D répond aux requêtes sur le port TCP 19812. Si ce port est déjà utilisé par un autre service ou si vos paramètres de connexion requièrent une autre configuration, vous pouvez changer le port TCP utilisé par le serveur SQL de 4D.

  Notes :
  - Si vous passez 0, 4D utilisera le numéro de port TCP par défaut, c'est-à-dire 19812.
  - Il est possible de définir cette valeur par programmation à l'aide du sélecteur Numéro de port serveur SQL de la commande FIXER PARAMETRE BASE.

• Adresse IP : Vous pouvez définir l’adresse IP de la machine sur laquelle le serveur SQL doit traiter les requêtes SQL. Par défaut, le serveur répond sur toutes les adresses IP (option Toutes).
  La liste déroulante “Adresse IP” liste automatiquement toutes les adresses IP présentes sur la machine. Lorsque vous sélectionnez une adresse particulière, le serveur ne répond qu’aux requêtes dirigées sur cette adresse. Cette fonctionnalité est destinée aux applications 4D hébergées sur des machines ayant plusieurs adresses TCP/IP.

  Notes :
  - Côté client, l’adresse IP et le port TCP du serveur SQL auquel l’application se connecte doivent être correctement configurées dans la définition de la source de données ODBC.
  - A compter de 4D v14, le serveur SQL prend en charge la notation d'adresses IPv6. Le serveur accepte indifféremment les connexions IPv6 ou IPv4 lorsque la configuration "Adresse IP" d’écoute du serveur est sur Toutes. Pour plus d'informations, reportez-vous à la section Prise en charge d’IP v6.

• Activer TLS : Cette option indique si le serveur SQL doit activer le protocole sécurisé TLS pour traiter les connexions SQL. A noter que lorsque ce protocole est activé, le mot-clé ":ssl" devra être ajouté à l'adresse IP du serveur SQL lorsque vous ouvrirez une connexion via la commande SQL LOGIN.
  Par défaut, le serveur SQL utilise des fichiers internes pour la clé et certificat TLS. Vous pouvez toutefois utiliser des éléments personnalisés : pour cela, il vous suffit de recopier vos propres fichiers key.pem et cert.pem à l’emplacement suivant : MaBase/Preferences/SQL (où "MaBase" représente le dossier/package de la base).

• Autoriser les requêtes Flash Player : Cette option permet d’activer le mécanisme de prise en charge des requêtes Flash Player par le serveur SQL de 4D. Ce mécanisme est basé sur la présence d’un fichier, nommé "socketpolicy.xml", dans le dossier de préférences de la base (Preferences/SQL/Flash/). Ce fichier est requis par Flash Player afin d’autoriser les connexions cross-domains ou les connexions par sockets des applications Flex (Web 2.0).
  Dans la version précédente de 4D, ce fichier devait être ajouté manuellement. Désormais, lorsque vous cochez cette option, les requêtes Flash Player sont acceptées et un fichier "socketpolicy.xml" générique est créé si nécessaire pour la base.
  Lorsque vous désélectionnez cette option, le fichier "socketpolicy.xml" est désactivé (renommé). Les requêtes Flash Player ultérieures reçues par le serveur SQL sont alors rejetées.
  A l’ouverture de la base, l’option est cochée ou non en fonction de la présence d’un fichier "socketpolicy.xml" actif dans le dossier de préférences.

  Note : Il est possible de définir l'encodage utilisé par le serveur SQL pour le traitement des requêtes externes à l'aide de la commande 4D SQL FIXER OPTION.

Pour des raisons de sécurité, il est possible de contrôler les actions que les requêtes externes adressées au serveur SQL peuvent effectuer dans la base de données 4D. Ce contrôle est effectué à deux niveaux :

• au niveau du type d’action autorisé,
• au niveau de l’utilisateur ayant effectué la requête.
  Ces paramétrages peuvent être effectués via la page SQL des Propriétés de la base.

Note : Vous pouvez également utiliser la Méthode base Sur authentification SQL afin de contrôler de manière personnalisée les requêtes externes au moteur SQL de 4D.

Les paramétrages définis dans cette boîte de dialogue s'appliquent au schéma par défaut. En effet, le contrôle des accès externes à la base est basé sur le concept des schémas SQL (cf. section Implémentations du moteur SQL de 4D). Si vous ne créez pas de schémas personnalisés, le schéma par défaut inclut toutes les tables de la base. Si vous créez d'autres schémas dotés de droits spécifiques et leur associez des tables, le schéma par défaut inclut uniquement les tables non incluses dans les schémas personnalisés.

Vous pouvez configurer séparément trois types d’accès au schéma par défaut via le serveur SQL :

• Lecture seulement (données) : libre accès en lecture à toutes les données des tables de la base mais ne permet pas l’ajout, la modification ou la suppression d’enregistrements ni la modification de la structure de la base.
• Lecture/écriture (données) : accès en lecture et en écriture (ajout, modification et suppression) à toutes les données des tables de la base mais ne permet pas la modification de la structure de la base.
• Complet (données et structure) : accès en lecture et en écriture (ajout, modification et suppression) à toutes les données des tables de la base et à la structure de la base (tables, champs, liens, etc).

Vous pouvez désigner un ensemble d’utilisateurs pour chaque type d’accès. Pour cela, vous disposez de trois types d’options :

• <Personne> : si vous sélectionnez cette option, le type d’accès sera refusé pour toutes les requêtes, quelle que soit leur provenance. Ce paramètre peut être utilisé même si le système de gestion des accès via des mots de passe de 4D n’est pas activé.
• <Tout le monde> : si vous sélectionnez cette option, le type d’accès sera accepté pour toutes les requêtes (aucun contrôle n’est effectué).
• groupe d’utilisateurs : cette option permet de désigner un groupe d’utilisateurs comme seul autorisé à effectuer le type d’accès associé. Cette option requiert que la gestion des mots de passe de 4D ait été activée. L’utilisateur à l’origine des requêtes fournit son nom et son mot de passe lors de la connexion au serveur SQL.

ATTENTION : Chaque type d'accès est défini indépendamment des autres. En particulier, si vous affectez un groupe uniquement au type d'accès Lecture seulement, cela n'aura aucun effet car le groupe ainsi que tous les autres continueront de bénéficier de l'accès Lecture/écriture (affecté à <Tout le monde> par défaut). Pour définir un accès Lecture seulement, il est nécessaire de configurer l'accès Lecture/écriture.

ATTENTION : Ce mécanisme s’appuie sur les mots de passe de 4D. Pour que le contrôle d’accès au serveur SQL soit effectif, le système de mots de passe de 4D doit être actif (un mot de passe doit avoir été attribué au Super_Utilisateur).

Note : Une option de sécurité supplémentaire peut être définie au niveau de chaque méthode projet 4D. Pour plus d’informations sur ce point, reportez-vous au paragraphe “Option “Disponible via SQL”” dans la section Implémentations du moteur SQL de 4D.