Discussion :

[[ZiP]]

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

[makowski]

les deux sont possibles
j'ai tout de même tendance à penser que

un seul utilisateur global avec une gestion dans une table des utilisateurs

est plus souple

[ShaiLeTroll]

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 !

[[ZiP]]

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

[skywaukers]

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

[[ZiP]]

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

[skywaukers]

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