Feature #9990
ferméRefactoriser MyDB pour le passer dans Silverpeas 6
100%
Description
MyDB est une application à la MS-Access et donc issue d'un autre temps dans lequel les considérations de sécurité laissaient le pas aux fonctionnalités et les attaques sur le Web étaient marginaux.
Le contexte actuel a changé et les contraintes de sécurité sont devenues cruciales pour les applications Web.
Or, MyDB, par sa nature, est une porte grande ouverte dans les remparts de la sécurité : parce qu'un utilisateur peut exécuter n'importe quelle requête de création, de suppression et de mise à jour d'une base de données, parce que les références à la base de données sont données en claires, il est possible alors à un attaquant, par des attaques d'SQL Injection, entre autre, de contourner toute sécurité et non seulement d'attaquer le système de base de données, mais aussi le serveur sur lequel tourne ce système de base de données. C'est la raison pour laquelle MyDB a été retiré de Silverpeas 6.
- les accès à la base de donnée cible de MyDB se fera par les fichiers de propriétés et donc à l'installation/configuration de l'application.
- la structure (le schéma) de la base de données cible devra être créée en dehors de Silverpeas.
- MyDB offrira le moyen non seulement de pouvoir requêter la base de donnée (comme avec JDBC Connector) mais aussi de modifier les données (et uniquement les données) dans cette base (insertion, mise-à-jour et suppression).
Quoiqu'il en soit, aucune commande SQL ne doit passer par l'interface Web ; autrement dit il ne devra pas être possible d'écrire des requêtes SQL, même limitées. Derrière, le moteur de MyDB ne devra permettre que du requêtage simple ; autrement dit pas d'instructions imbriquées possibles.
Fichiers
Mis à jour par Miguel Moquillon il y a plus de 6 ans
- Statut changé de New à In progress...
- Assigné à mis à Miguel Moquillon
Mis à jour par Miguel Moquillon il y a plus de 6 ans
- Fichier mydb-datasource_setting.png mydb-datasource_setting.png ajouté
- Fichier mydb-tableNoSelected-admin.png mydb-tableNoSelected-admin.png ajouté
- Fichier mydb-tableNoSelected-publisher.png mydb-tableNoSelected-publisher.png ajouté
- Fichier mydb-tableNoSelected-reader.png mydb-tableNoSelected-reader.png ajouté
- Fichier mydb-tableSelected-publisher.png mydb-tableSelected-publisher.png ajouté
- Fichier mydb-tableFiltered.png mydb-tableFiltered.png ajouté
- Fichier mydb-tableRowDeletion.png mydb-tableRowDeletion.png ajouté
- Fichier mydb-tableRowUpdate.png mydb-tableRowUpdate.png ajouté
- Fichier mydb-tableRowAdding.png mydb-tableRowAdding.png ajouté
- Fichier mydb-tableSelected-reader.png mydb-tableSelected-reader.png ajouté
- Statut changé de In progress... à Resolved
- % réalisé changé de 0 à 100
MyDB a été restauré et le code a été profondément mis à jour pour la V6.
La version de MyDB pour Silverpeas 6 a été réalisée à partir du code de JDBCConnector. Il ne sera alors pas étonnant d'y retrouver des ressemblances dans leur IHM.
Pour commencer, on y retrouve la sélection de la base de données par le gestionnaire de JDBCConnector :
Une fois la base de donnée sélectionnée, le gestionnaire arrive sur la page de sélection de tables dans ladite base de données. Au début, cette page est vide parce qu'aucune table a été sélectionnée :
Le publieur peut lui même sélectionner la table sur laquelle il souhaite travailler :
Le lecteur ne peut lui que consulter la table qui a été sélectionnée au préalable par un gestionnaire ou par un publieur. Au début, la page sera vide :
Lorsque le gestionnaire ou le publieur sélectionne une table, l'ensemble de son contenu sera alors affiché (le nombre de lignes maximum est conditionné par le paramètre "Lignes Max" dans la sélection de la base de données) :
A ce moment là, tout lecteur pourra lui aussi consulter le contenu de la table sélectionnée :
Il pourra, comme pour le gestionnaire ou le publieur filtrer le contenu à afficher :
Mais seuls les gestionnaires et les publieurs pourront supprimer des lignes de la table :
ou modifier certaines d'elles :
ou encore ajouter de nouvelles lignes :
L'insertion, la modification et la suppression se fait donc par l'IHM. Même si l'utilisateur n'a pas à saisir d'instructions SQL en directe, une connaissance de SQL est tout de même requise, pour pouvoir, par exemple, valoriser correctement les différents champs d'une ligne (tuple) d'une table en modification ou en ajout. Toute erreur est aussitôt remontée.
Mis à jour par Miguel Moquillon il y a environ 6 ans
- Fichier mydb-rowEditionWithFK.png mydb-rowEditionWithFK.png ajouté
- Fichier mydb-rowEdition-FkView.png mydb-rowEdition-FkView.png ajouté
Les clés primaires auto-générées sont prises en comptes. Ces champs ne sont pas alors proposés dans le formulaire d'ajout d'un nouveau tuple. A savoir que les clés primaires ne sont pas du tout proposées pour modification dans le formulaire de mises à jour d'un tuple existant.
Lorsqu'un champ est une clé étrangère qui pointe donc sur une autre table de la base de donnée, un icône correspondant est affiché à côté dudit champs dans le formulaire de la mise à jour dans celui de création d'un tuple. A savoir que les clés étrangères composites ne sont pas supportées.
Un clic sur cet icône ouvre une popin sur la table référencée par la clé étrangère en vue de sélectionner le tuple vers lequel pointera la clé étrangère.
Mis à jour par Nicolas Eysseric il y a environ 6 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Nicolas Eysseric il y a environ 6 ans
- Statut changé de Integration in progress... à Closed
Validé et intégré