A propos de la sécurité des applications 4D Mobile

Une fois les données des tables de la base 4D exposées en 4D Mobile et intégrées au catalogue de l'application Wakanda, vous devez restreindre l’accès à certaines ressources "sensibles".

A la différence des applications 4D, les applications Web ne permettent pas de contrôler via l’interface les données exposées : par exemple, il ne suffit pas de ne pas afficher un champ dans un formulaire pour le rendre réellement inaccessible à l’utilisateur. Les requêtes HTTP et l’utilisation du JavaScript permettent aux utilisateurs malveillants d’obtenir potentiellement toute information d’un serveur Web insuffisamment protégé. 

Le propos de cette section n’est pas de lister toutes les mesures de sécurité à prendre dans les applications 4D Mobile mais de fournir les pistes permettant de sécuriser de manière minimale les données exposées. 

• Protection des accès via 4D Mobile à la base 4D : vous devez contrôler les demandes de connexion 4D Mobile (via REST). Vous pouvez utiliser au choix :
  
  • les mots de passe 4D (cf. Contrôles automatiques par mot de passe 4D),
  • la Méthode base Sur authentification 4D Mobile.

• Contrôle de l’exposition 4D Mobile côté 4D : chaque table, attribut et méthode peut être ou non exposé en 4D Mobile. N’exposez que les données et méthodes strictement nécessaires, il est par exemple inutile d’exposer des champs non utilisés.

• Protection des données exposées : vous devez utiliser les systèmes de sécurité proposés par Wakanda pour contrôler le contenu accessible via les navigateurs. Plusieurs moyens (non exclusifs) s’offrent à vous :
  
  • Régler la portée (scope) des attributs et des méthodes provenant de la base 4D. En particulier, vous pouvez leur affecter la portée Public on Server, ce qui signifie que leur accès est libre pour le code s’exécutant sur le serveur, mais qu'ils ne sont pas accessibles sur les clients Web. Ce paramétrage s’effectue dans le fichier .js de configuration du modèle externe (cf. paragraphe Modifier le modèle externe).
    
  • Utiliser les attributs calculés : les attributs calculés se manipulent comme des attributs standard mais leurs valeurs sont retournées par des fonctions spécifiques (onGet, onSet...) exécutées lors des accès aux champs (événements). Ce principe permet de ne pas exposer les champs de la base 4D, mais uniquement les attributs calculés nécessaires. Les accès aux champs 4D sont effectués de manière sécurisée depuis le serveur Wakanda. Vous pouvez ajouter des champs calculés dans le fichier .js de configuration du modèle externe (cf. paragraphe Modifier le modèle externe). Pour plus d’informations, reportez-vous à la page Attributes de la documentation de Wakanda.
  • Combiner datastore class étendues et requêtes restrictives (restricting queries): ce concept puissant permet de contrôler non seulement les attributs exposés mais également les données qu’ils peuvent afficher. Etendre une datastore class signifie en créer une copie (la classe dérivée) que vous pouvez altérer en lui ajoutant des attributs calculés ou en supprimant des attributs. Vous pouvez lui associer une restricting query : dans ce cas, tous les accès aux données de la classe dérivée déclenchent automatiquement cette requête, qui retourne uniquement les enregistrements correspondant au(x) critère(s). Ce principe vous permet de lier les données à l’utilisateur connecté au serveur Wakanda. Par exemple, dans le cadre d’une base commerciale, la requête retourne tous les clients rattachés au commercial courant. Bien entendu, seule la classe dérivée sera accessible aux clients Web.
    Vous créez des datastore class étendues et ajoutez des restricting queries dans le fichier .js de configuration du modèle externe (cf. paragraphe Modifier le modèle externe). Pour plus d’informations, reportez-vous à la page Programming Restricting Queries de la documentation de Wakanda.
  Note : La prise en charge des requêtes restrictives dans 4D Mobile requiert au minimum la configuration suivante :
  - 4D et 4D Server v14.1
  - Wakanda Enterprise Server v8