Version imprimable
Bonjour,
Actuellement au stade de l'étude, j'envisage de développer une application commerciale qui utiliserait une base de données distante Firebird.
L'accès à cette application se ferait avec un identifiant et un mot de passe correspondant à un utilisateur de la base de données Firebird.
Ce type de fonctionnement vous semble-t-il correct ou alors, vaut-il mieux un seul utilisateur global avec une gestion dans une table des utilisateurs ?
Merci,
ZiP
les deux sont possibles
j'ai tout de même tendance à penser queest plus soupleCitation:
un seul utilisateur global avec une gestion dans une table des utilisateurs
C'est toujours problématique !
La plupart des applications que j'ai vu gérait le propre système de connexion avec une table d'utilisateurs !
une simple table contenait Login, Password et droits
Password chiffré (généralement un simple XOR sur une clé + Encodage Base64, parfois l'AES intégré à MySQL ou Windows)
Parfois le login était aussi chiffré !
Un exemple que j'ai vu commun à TOUTES les applis de la société
Les Droits pouvaient être une simple lettre ou chiffre (réservé aux utilisateurs spéciaux)
Chaque action dans la TActionList avait une category, si la lettre de l'utilisateur est dans la category, le TAction était visible !
Un utilisateur A pouvait ainsi utiliser le Menu category A, AB, ABC... l'utilisateur B pouvait utiliser category AB, ABC...
Parfois A, B, C... était un ordre logique, A pour Admin, B pour utilisateur élevé, C pour utilisateur réduit ... et d'autres fois c'était une lettre par module applicatif C comme Compta, R comme Radiologie, S comme Système...
Dans certaines applications, les droits allait jusqu'à la ligne dans la table, c'est à dire que l'on était propriétaire d'une fiche, on pouvait autoriser les membres d'un groupe à voir ou même modifier la fiche, on pouvait aussi invité des utilisateurs d'un autre groupe (sans inviter tous le groupe)
Cela réparti sur plusieurs tables et assez complexes !
Une autre pratique courante était le LDAP ainsi l'utilisateur utilisait son email ou son identifiant Windows pour se connecter !
Ensuite, pour la connexion à la DB, elle était souvent unique
j'ai aussi vu des droits qui étaient gérés par module applicatif pour restreintre le niveau d'accès à certaines tables.
Dans un projet, c'était une même DB partagée pour plusieurs logiciels web, chaque "appli" avait son login pour ne pas voir les tables de l'autre "appli"
Dans un autre projet, c'était une seule appli (un CMS) et chaque module\sous-module pouvait avoir un ou plusieurs user DB
Par exemple, en Compta, on ne supprimais jamais, la suppression était un marquage ou alors une annulation qui s'exprimait par une autre ligne dans le journal ...
Donc pour le module Compta, l'utilisateur DB n'avait que SELECT, UPDATE, INSERT mais pas DELETE (ça c'était selon la criticité de la table)
Idem le module de STATCompta ou de REPORTCompta pouvait faire des que SELECT sur les tables de données de la Compta et quasiment tous les droits sur les tables temporaires ou de travail des rapports
Lors de la création d'un utilisateur, on lui affectait un profil utilisateur, ce profil lui était en réalité un ensemble de login DB, ainsi certains utilisateurs pouvaient être représenté par un seul et unique user DB, certains par une petite dizaine !
Ce modèle proche de la paranoïa me semble pénible à maintenir, oblige d'avoir une structure pure POO qui encapsule tous les traitements DB (dont le sélecteur de connexion), d'avoir de bonnes spec et doc technique, il semble indispensable de respecter et tenir une même norme entre les développeurs d'une équipe et d'éviter les raccourcis (ou contournement) car c'est souvent ce que l'on voit, un beau modèle théorique de départ qui dans la pratique devient un bazar total !
Bonsoir,
En fait, j'ai posé cette question car je souhaite héberger la base de données Firebird et distribuer un programme qui permet de s'y connecter.
C'est pourquoi je vois plus un accès par utilisateur et non un accès global géré ensuite par utilisateurs.
En effet, si le mot de passe "administrateur" est détecté dans mon programme, on a accès à tout...
Cordialement,
ZiP
Bonsoir,
quelle que soit ta solution, je ne pense pas qu'il soit judicieux de te connecter à la base de données avec son compte administrateur depuis ton application.
@++
Dany
Bonsoir,
Je suis d'accord avec vous, mais si j'utilise un compte de connexion (avec beaucoup de droits) pour ensuite gérer mes utilisateurs et droits dans une table, le compte de connexion à la base de données a beaucoup de droits.
Je vais y réfléchir.
Merci,
ZiP
Re,
l'idéal dans ton cas serait de passer par un serveur intermédiaire qui s'occuperait des accès à la base de données et qui n'exposerait que les méthodes nécessaires à ton client. Là tu peux alors gèrer une table d'utilisateurs propre à l'application et aucun compte de la base de données n'est exposé.
@++
Dany
Bonjour skywaukers,
Quoi que dans mon cas, les clients vont se connecter pour faire uniquement de la consultation de données, c'est donc beaucoup moins risqué.
Il faut que je regarde le système de gestion des droits de Firebird.
Merci,
ZiP
Bonjour,
ok, donc effectivement tu peux créer un user dans firebird qui n'aura le droit qu'à faire des select sur les tables.
Après il faut voir la criticité de la base de données. L'exposer directement sur le web va permettre à un éventuel hacker de retrouver tes requettes et d'en déduite la structure de la base. Après si il connait une faille... Passer par un serveur intermédiaire te protège également de cela en limitant les accès à seulement ce que tu as prévu.
à++
Dany
@[ZiP], tu as lu ma réponse ?
L'utilisation de plusieurs connexion avec des droits finement affectés en fonction module\profil
Si chaque utilisateur (groupe d'utilisateur) doit avoir SES propres données et uniquement les siennes !
Tu peux ajouter dans chaque table, un id user, et dans tous les requêtes tu gère cet id, ainsi dans la même table, tu auras des données pour plusieurs utilisateurs
J'ai utilisé ce modèle dans un projet PHP+MySQL, la gestion de l'id user était via un système de groupe (pas un simple arbre mais un graphe avec des groupes recoupant d'autres groupes, les jointures générées à la volée étaient montreuses), chaque niveau de groupe ayant des droits spécifiques pour lire, écrire, effacer la fiche (droit façon linux)
Sinon, tu peux faire une DB par utilisateur\groupe
Tu as une DB principal accessible à tous en SELECT
Cette DB principale contient la table des Login et lie un user avec sa DB
Pense que plusieurs users peuvent partager la même DB
tu peux avoir un user pouvant utiliser plusieurs DB
J'ai exactement appliqué ce modèle pour un projet, si l'utilisateur n'avait qu'une DB, cela ouvrait directement sa DB mais si il en avait plusieurs, il devait choisir la DB via une petite combobox contenant des libellés compréhensible pour l'utilisateur lui permettait de cibler la bonne DB
Ce choix était obligatoire, avant le logiciel était installé sur 10 serveurs pour chaque "entité", une entité c'était entre 2 à 10 utilisateurs.
Dans une logique de centralisation, il fallait faire cohabiter les 10 DB de chaque entité sur le même serveur pour justement faciliter à certaines personnes l'accès à plusieurs "entité" et à la mise en web
Je suis habitué à MySQL, un serveur peut héberger plusieurs DB !
J'espère que Firebird fonctionne de la même façon
Oui Firebird permet de gérer plusieurs DB.Citation:
Envoyé par ShaiLeTroll
@++
Dany
Bonsoir,
Merci ShaiLeTroll et skywaukers pour vos réponses !!!
ZiP