Accès SQL Read only

Simplicité 5.1.59

Bonjour,

est-il possible de limiter la fonctionnalité d’accès BDD à des requêtes READ ONLY ?
image

Merci d’avance

Non cet outil est un outil de dev volontairement utilisable pour tout type de requêtes SQL, ce n’est pas sensé être mis dans les mains d’utilisateur métier.

Pouvez vous nous décrire quel besoin vous amène à poser cette question ? Il y a peut être d’autres approches possibles car accéder directement à la base, à fortiori via la UI, est plutôt un anti pattern.

C’est pour les administrateurs techniques de l’application qui interviennent au niveau de l’exploitation.

Ils souhaitent avoir l’accès BDD mais uniquement si c’est un accès Read Only.

Merci en tout cas pour votre retour.

En fonction des types de requêtes qu’il souhaitent faire c’est peut être plutôt des objets dédiés (notamment des objets “select”) qui repondraient au besoin.

Il n’est jamais bonne chose de donner accès à la base depuis les couches applicatives.

On toujours peut regarder pour brider le composant DBAcces à du select mais s’il y a une autre approche ça me semble plus raisonnable

Merci pour les informations. Je sais pas ce que sont les objets “select”. Si c’est au sens vue (héritage d’un objet en lecture seule par exemple) alors ça ne répondrait pas au besoin.

Il souhaitent un accès à la BDD mais les accès à la BDD en direct (dépuis un client) est proscrit dans l’architecture actuelle.

Une dernière question : est-ce que les requêtes SQL exécutées depuis cette fenêtres sont historisées/historisables et liées à l’utilisateur qui les exécute dans les logs ?

Un objet “select” est un objet pour lequel le designer définit une requête SQL spécifique. Il y a des exemples dans la demo:

Conceptuellement c’est une “vue” = un objet fait pour du read only (puisque c’est un select) mais ça bénéficie des mécanismes standards applicables à tout objet métier = droits, pagination, attributs filtrables, recherches prédéfinies, tableaux croisés, etc.

Le composant DBAccess est fondamentalement un outil de dev à mettre dans les mains de gens qui savent ce qu’ils font et à ne jamais utiliser en PROD (sauf cas exceptionnel)

Ce n’est pas un outil métier donc, non il n’y a pas d’historisation des requêtes (autre qu’en mémoire pendant la session) ni traçabilité particulière (autre que la traçabilité SQL standard).

Si votre besoin c’est de gérer un “catalogue” de requêtes rejouables ça devient du métier = à modéliser (ex: un objet “Requête” avec un attribut texte SQL et un mécanisme pour récupérer le résultat de la requêtes = un attribut fichier avec le CSV résultant, ou un objet lié pour historsier les CSV résultants, une action, etc.)

Dans tous les cas je maintient qu’il n’est jamais sain de mettre dans les main d’utilisateurs métier (même si le métier c’est exploitant) des mécanismes pour faire des requêtes SQL libres = risques en termes de droits, risques légaux (ex: RGPD), risques techniques (ex: si grosse requête qui finit en out of memory) etc.

Si votre client interdit les accès en base via un outil de base de données ce n’est sans doute pas pour que cette interdiction - à priori légitime - soit contournée par des outils au niveau applicatif.

Merci pour vos retour. Je clos le sujet.

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.